程序员重构入门指南

文章首发于公众号「架构师指南」及个人博客 shuyi.tech，欢迎关注访问。

对于刚入门的编程者来说，《重构》是一本不错的读物。它能给你带来一些重构思想上的改变，告诉你为什么要重构，应该怎么做重构。本文基于《重构》一书，整理重构所需的「思想」与「技巧」上的准备。

思想篇指的是对于重构的认识，理解这些思想能够让你更好地做好重构。而技巧篇指的是具体重构时的一些技巧，能够让你知道怎么写出更好的代码。

思想篇

重构之前先建立测试用例

重构的第一步，是为即将修改的代码建立一组可靠的测试用例。预见建立好的测试用例，是你的安全绳，它能告诉你工作是否完成了，是否存在可能的缺陷。

重构的价值

重构可以改进软件的设计。就像在不断整理代码一样，经常性的重构可以帮助代码维持自己该有的形态。重构使得软件更容易理解，不要让几个月之后其他人（甚至自己）也读不懂你的代码，清晰易懂的代码能让你更快理解代码的意图。重构能帮助找到bug，因为重构是小步快跑的，每一步都有一个猎手（测试用例）帮你抓到猎物（bug）。

好的重构，最终能帮你提高编程速度，提高编程带来的愉悦感。

什么时候重构？

什么时候重构？第一次只管去做，第二次会反感，第三次应该重构。事不过三，三则重构。

专门拨出时间重构是不可能的，我们需要在日常工作中不断地重构。但是还没开始有重复的功能，就想着重构，那太可笑了。但是重复的代码或者代码有问题，超过三次之后还不动手，那么就有点偷懒了。

什么时候不重构？

当现有代码根本不能正常运作的时候，你应该重写，而不是重构。

重构应该是一个习惯

重构应该是一种工作习惯，在日常工作中一点点重构，而不是妄想有专门的时间重构。我们曾经进行的一些大型重构，需要数月甚至数年的时间。如果需要给一个运行中的系统添加功能，你不可能让系统停止2个月去重构。你只能一点点地做你的工作，今天一点点，明天一点点。

如何测试？

我们的时间总是有限的，测试你最担心出错的部分，这样你能得到最大的收益。测试的时候，寻找边界条件，集中火力测试那里！

什么时候取消重构？

如果你感觉到重构失控了，那么最好的办法是取消重构，回到你的安全区去。等你重新能掌控的时候，再来做重构。

重构的团队意识

进行大规模重构时，有必要为整个开发团队建立共识。整个团队都必须意识到：有一个大型重构正在进行，每个人都应该相应地安排自己的行动。

设计模式帮助你重构

学习设计模式可以很好地帮助你重构，它能在适当的场合帮助你承载复杂的业务。但你不应该简单地了解，而是要多对比各个设计模式之间的区别，它们解决了什么问题，适用于什么场合。

技巧篇

不要出现重复代码

当出现重复代码时，你应该提取出公共方法。我想这个说得已经足够清楚了，当出现重复代码的时候就需要想想：我是否需要抽离出重复的代码？

不要出现过长、过短的函数

当函数过长，你应该根据业务逻辑提炼出多个函数。那一个函数多少行算是长呢？按我个人理解，一个函数在 20-50 行是比较合适的。但这也只是一个经验值，最根本的判断标准是：别人阅读你的代码的时候，是否能很清晰、很方便地读懂。 如果你写得很长，但是别人读得时候很舒服，那么也可以。

要注意函数过短也会带来阅读的困难，他会让你多次跳转，打断你的阅读思路。所以如果一个函数内容过短，你需要考虑是否去掉这个函数。简单地说，你还是应该根据业务逻辑结构化，将每块业务逻辑放到合适的函数中。

不要出现过大的类

当类过大，你应该考虑是否能拆分出多个类。或者你应该考虑，你的类抽象体系是否出现了问题。一个过大的类与过长的函数一样，会让人感觉到压抑、难于读懂。

不要让参数过长

当参数列过长，你应该使用对象参数。

提炼发散式变化

因为一个变化，而需要修改多个地方，这说明出现了发散式变化，你需要考虑将变动的代码合并在一起。

提炼对象

总是绑在一起出现的数据，需要把他们提炼到一个独立对象中。

引入解释性变量

不要让你的变量或表达式没有语义，必要时引入解释性变量。很多人会习惯性地用 flag 去承载一个表达式的值，但这并不是一个好的习惯。变量命名还是应该更加语义化，这样我们能更加清晰地明白这个变量的作用。

搬移函数

一个函数被另一个类调用得很频繁，那你可能得考虑把这个函数搬移到另一个类中。

搬移字段

一个字段被另一个类用得很频繁，或许你改考虑把这个字段搬移到另一个类中。

提炼类、简化类

某个类做了应该由两个类做的事情，此时应该提炼出一个新类，然后用组合关系组合起来。这其实与 SOLID 原则想契合，一个类应该是单一职责的，如果某个类做了两个类的事情，那说明其承担的职责就复杂了，因此需要抽离出一个新类出来。

而如果一个类并没有太多内容，这时候就应该考虑是否去掉这个类，优化整个类结构。