代码重构

早起第九天-代码重构

图/unsplash @paysonwick

其实我是个程序员，今天想说一说重构。

其实我是个程序员，今天想说一说重构。

看过几本关于重构的书籍，例如《重构，改善既有代码的设计》，《重构与模式》以及最近在看的设计模式等，虽然每次都是浅尝则止，但也学到了点东西，加上工作中偶尔也会进行一些重构，所以有一点心得体会。

什么是重构

Martin Fowler 是这样定义重构的："重构是一种对软件内部结构的改善，目的是在不改变软件的可见行为的情况下，使其更易理解，修改成本更低。"

简单来说，就是在不改变最终逻辑行为的前提下，将代码改写得让人更容易理解和灵活。

为什么要重构

有很多原因，比如说项目之初，时间上来不及，设计上没有考虑扩展性，以至于之后每次新增功能都要改动到已有代码，造成很高的风险。或者不同人一起维护的代码，各自有各自的开发习惯，即便是同一个人写的，时间久了也会显得杂乱无章，维护已有代码的成本可能已经比新开发一套代码的成本还要高了。

你可以说，当项目快进行不下去了，这时候可能就需要重构。

如何重构

首先要找出代码的坏味道和设计上的不足之处，这并不容易，往往需要对业务和技术有深入的理解，才能确定哪些东西应该归于哪里，以及未来的需求可能出现的变化，这样才能在重构的时候兼具未来，设计出高内聚低耦合扩展性良好的代码。

PS： 这里很幸运我的领导是某一领域的领域专家。

除非项目走不下去了，否则我们一般不会专门抽出时间来重构，因为这个投入产出比效果还不看上去并不明显。所以我们当前的重构往往是小步快跑。

我把它分为四个阶段

编码前的分析设计阶段

多参与项目的需求分析，可行性分析，多一点业务理解。在详细设计阶段，一定要把自己的设计方案用时序图或者 ER 图画出来，然后叫上同事们一起来 review 你的设计方案。

我觉得这一步特别重要，一个人对业务和技术的理解往往有限，叫上同事一起 review 设计能发现很多问题。

开始编码阶段

因为设计方案已经review过了，所以这个时候不怎么会出大问题了，注意命名规范，方法的可测试性，以及上帝的归上帝，凯撒的归凯撒的，就是该是谁的东西就放在谁那，做到高内聚低耦合，不过好些时候会当局者迷，写了不规范的也不自知。

代码 review 阶段

推荐 git rebase 配合 source tree 一起使用。如下图，即使多人写作，那么提交记录也是清晰的一条直线，点击可查看每次改动的详情，非常适合当下就 review 。

这样在团队合作时，可以清晰得看到同事每一次的提交，有空就可以看看同事提交的代码。另外最好每次小步快跑，每次提交只实现一个需求或者修改一个 bug ，好处多多，不要等到一大堆代码几十个文件 change 的时候，喊同事进小黑屋 review 代码，那样效率太低，往往只是走个形式，没啥大作用。

后期维护阶段

因为项目都是不断迭代的，在每次改动涉及到原有需求的时候，可以顺便看一看有没有哪里是当初设计不合理的，可以一点一点优化，有时候可能只是把某个方法移到其他类中，有时候可能只是改个名字，然后测试没问题就可以发布了。这都是小小的重构，如果涉及到设计方案的重构，就需要花大量时间来调整，这个风险太高，得有充分的时间和测试才行。

总之，重构的过程其实很有趣，有时候会让人有成就感，当然如果大重构也会有很高的风险，对于业务和技术的能力都是一个挑战。我们更应该尽量做好每一个小功能，设计好小方法，如果以分治思想来看，每一个小的做好了，那么大的也就好了。虽然不尽如此，但也大同小异。