美团：怎样写出漂亮整洁的代码？聊聊clean code的编码、重构技巧( 二 ) _代码

小步快跑，不要企图一口吃成个胖子。改一点，测试一点，一方面减少代码merge的痛苦，另一方面减少上线的风险。

建立自动化测试机制，要做到即使代码改坏了，也能保证系统最小核心功能的可用，并且保证自己修改的部分被测试覆盖到。

熟练掌握IDE的自动重构功能。这些会很大程度上减少我们的体力劳动，避免犯错。

静态检查
现在市面上有很多代码静态检查的工具，也是发现bug和风格不好的比较容易的方式。可以与发布系统做集成，强制把主要问题修复掉才可以上线。目前美团点评技术团队内部的研发流程中已经普遍接入了Sonar质量管理平台。
多读开源代码和身边优秀同学的代码
感谢开源社区，为我们提供了这么好的学习机会。无论是JDK的源码，还是经典的Netty、Spring、Jetty，还是一些小工具如Guava等，都是clean code的典范。多多学习，多多反思和总结，必有收益。
代码整洁的常见技巧
前面的内容都属于热身，让大家有个整体宏观的认识。下面终于进入干货环节了，我会分几个角度讲解编写整洁代码的常见技巧和误区。
通用技巧单一职责
这是整洁代码的最重要也是最基本的原则了。简单来讲，大到一个module、一个package，小到一个class、一个method乃至一个属性，都应该承载一个明确的职责。要定义的东西，如果不能用一句话描述清楚职责，就把它拆掉。
我们平时写代码时，最容易犯的错误是：一个方法干了好几件事或者一个类承载了许多功能。
先来聊聊方法的问题。个人非常主张把方法拆细，这是复用的基础。如果方法干了两件事情，很有可能其中一个功能的其他业务有差别就不好重用了。另外语义也是不明确的。经常看到一个get()方法里面竟然修改了数据，这让使用你方法的人情何以堪？如果不点进去看看实现，可能就让程序陷入bug，让测试陷入麻烦。
再来聊聊类的问题。我们经常会看到“又臭又长”的service/biz层的代码，里面有几十个方法，干什么的都有：既有增删改查，又有业务逻辑的聚合。每次找到一个方法都费劲。不属于一个领域或者一个层次的功能，就不要放到一起。
我们team在code review中，最常被批评的问题，就是一个方法应该归属于哪个类。
优先定义整体框架
我写代码的时候，比较喜欢先去定义整体的框架，就是写很多空实现，来把整体的业务流程穿起来。良好的方法签名，用入参和出参来控制流程。这样能够避免陷入业务细节无法自拔。在脑海中先定义清楚流程的几个阶段，并为每个阶段找到合适的方法／类归属。
这样做的好处是，阅读你代码的人，无论读到什么深度，都可以清晰地了解每一层的职能，如果不care下一层的实现，完全可以跳过不看，并且方法的粒度也会恰到好处。
简而言之，我比较推崇写代码的时候“广度优先”而不是“深度优先”，这和我读代码的方式是一致的。当然，这件事情跟个人的思维习惯有一定的关系，可能对抽象思维能力要求会更高一些。如果开始写代码的时候这些不够清晰，起码要通过不断地重构，使代码达到这样的成色。
清晰的命名
老生常谈的话题，这里不展开讲了，但是必须要mark一下。有的时候，我思考一个方法命名的时间，比写一段代码的时间还长。原因还是那个逻辑：每当你写出一个类似于"temp"、"a"、"b"这样变量的时候，后面每一个维护代码的人，都需要用几倍的精力才能理顺。
并且这也是代码自描述最重要的基础。
避免过长参数
如果一个方法的参数长度超过4个，就需要警惕了。一方面，没有人能够记得清楚这些函数的语义；另一方面，代码的可读性会很差；最后，如果参数非常多，意味着一定有很多参数，在很多场景下，是没有用的，我们只能构造默认值的方式来传递。
解决这个问题的方法很简单，一般情况下我们会构造paramObject 。用一个struct或者一个class来承载数据，一般这种对象是value object，不可变对象。这样，能极大程度提高代码的可复用性和可读性。在必要的时候，提供合适的build方法，来简化上层代码的开发成本。
避免过长方法和类
一个类或者方法过长的时候，读者总是很崩溃的。简单地把方法、类和职责拆细，往往会有立竿见影的成效。以类为例，拆分的维度有很多，常见的是横向／纵向。例如，如果一个service，处理的是跟一个库表对象相关的所有逻辑，横向拆分就是根据业务，把建立／更新／修改／通知等逻辑拆到不同的类里去；而纵向拆分，指的是把数据库操作/MQ操作/Cache操作/对象校验等，拆到不同的对象里去，让主流程尽量简单可控，让同一个类，表达尽量同一个维度的东西。