今天的主题是代码重构。好的代码像刚出浴的美人，怎么看都看不够，给人一种舒服的感觉；糟糕的代码像邋遢的人，脏乱差，没人愿意阅读。作为一个轻度强迫症，每次看到这样的代码，都难以忍受。

说到代码重构，让我想起吴军在《文明之光》里讲到的“垄耕种植法”，它由中国人发明创造，后传至欧美，影响了全世界的粮食生产。据说欧洲人民还没掌握这项技术以前，他们把种子随意地撒在地里，任其自由生长，结果收成很低，如果种下20斤，大概只能收获60斤左右粮食。而中国早在先秦时期亩产最少都在240斤以上，2007年我国小麦亩产达到720斤，这都得益于“垄耕种植法”。

写代码很像种地，要想有个好收成，就要好好管理代码，让它们有组织有纪律。嘿，看着多精神！当你看到糟糕的代码，是改，还是不改？改吧，花时间；不改吧，会有隐患，可能将来就掉进这个坑，到时无论怎么骂娘都无济于事。闲话少说，就说怎么改，以下是我认为比较有用的最优实践：

一、重构是什么

简单说，重构是不影响程序外部行为的前提下，改善内部结构，让软件设计更好，更容易理解，更持久、健壮、可扩展。

二、任务分解

首先是任务分解，将整个业务分解模块，模块分解子模块，细之再细（称为精细），直到不能再分。而不是把所有的业务逻辑放一堆，那会让可读性非常差。一般来说，人的关注点超过一个界限就不太能集中注意力，而出错的概率也会相应地提高。

经常会看到一些代码，他把所有逻辑放在一个方法体，从上往下读，先读第一块逻辑，读了很久还没看到第二块逻辑，这种代码阅读起来，体验非常差。人的思维一般倾向于先整体再局部，否则很像“盲人摸象”，无法认清真相。看来，分解任务的方法也要符合人性的特点！

三、避免重复

避免重复就是程序的复用性，如果一个功能有两处需要用到，就要考虑抽象成工具类或工具方法。往往只是多花一点点时间，就能让维护的效率成倍增加，何乐而不为。程序丧失了复用性，也就不叫程序，就成了手工处理，纯手工打造费事费力。避免重复性，最重要是时刻要有“工具”思维，怎么让一个代码尽可能处理更多的业务，也就是“抽象”思维。

四、排列布局

优先级很重要，很重要，很重要！任务分解成无法再分的原子后，按优先级将之排列，优先级高的（关键业务）放在最显眼地方，比如放到类的最上面。就像手机桌面，你一定会把最常用的软件放在首页；这样，修改或找Bug时就能快速定位和排查。更多时候，这一点主要是针对某个类或架构的某一层，让它们看起来清晰明了，结构化。另外，好的代码结构更容易看清业务逻辑，抽象起来也很容易。

五、格式、变量、注释、条件判断

格式，是我最在意的一个细节，它就像是一个人的脸面，格式不好的代码，很难勾起别人的欲望（你在想森么）。平时敲代码，我都是自带格式化，不需要格式化工具，你可能会说这很费时间。其实，当把它养成习惯并深入骨髓，一点都不花时间，很享受，不信试试？清爽的格式，让你精神倍增，促使更多的产出。永远相信，慢就是快！所以，该缩进的缩进，该换行的换行，该对齐的对齐，该空格的空格，该注释的地方不要偷懒。

变量的命名，就是语义明确，看名知义。如果变量名都是 a,b,c,i,j,k，就脱离了业务，技术永远为业务服务。有语义的变量，才贴近业务 ，才有人性，否则就是空中楼阁。

关于注释，有人说，当你想要给代码加注释时，请先尝试重构，好的代码让注释变得多余（《代码重构》）。还有人说，一眼就能理解的代码不需要加注释。知乎上有一种说法，我是比较赞同：“注释一定要有，但不需要太多，少而精是最好的。一定要重视并写好注释，为了凑数而写注释不如不写。”类和方法上的注释一般是不能省的，业务代码的注释就要看情况而定。如果代码清晰，逻辑明了，变量名又很有“人性”，注释可以不写。

条件判断指的是代码块里的if判断，当一个判断很复杂很长时，一定要拿出来单独定义一个布尔变量，或定义一个判断方法。有时if判断的代码都会超出屏外，阅读起来很混乱。还有，if和其他嵌套不要超过3层。

六、结语

什么时候重构，我想最简单的判定是：当你读不懂一块代码或读起来很费力时，就要考虑重构了。另外，重构应该是随时随地，不要想单独拿时间去重构，看到不好的代码，立马就修掉，世界就会清净一点点。

At 2017.01.05