文章首发于公众号「架构师指南」及个人博客 shuyi.tech，欢迎关注访问。
文章首发于公众号「架构师指南」及个人博客 shuyi.tech，欢迎关注访问。
对于刚入门的编程者来说，《重构》是一本不错的读物。它能给你带来一些重构思想上的改变，告诉你为什么要重构，应该怎么做重构。本文基于《重构》一书，整理重构所需的「思想」与「技巧」上的准备。
思想篇指的是对于重构的认识，理解这些思想能够让你更好地做好重构。而技巧篇指的是具体重构时的一些技巧，能够让你知道怎么写出更好的代码。
思想篇
重构之前先建立测试用例
重构的第一步，是为即将修改的代码建立一组可靠的测试用例。预见建立好的测试用例，是你的安全绳，它能告诉你工作是否完成了，是否存在可能的缺陷。
重构的价值
重构可以改进软件的设计。就像在不断整理代码一样，经常性的重构可以帮助代码维持自己该有的形态。重构使得软件更容易理解，不要让几个月之后其他人（甚至自己）也读不懂你的代码，清晰易懂的代码能让你更快理解代码的意图。重构能帮助找到bug，因为重构是小步快跑的，每一步都有一个猎手（测试用例）帮你抓到猎物（bug）。
好的重构，最终能帮你提高编程速度，提高编程带来的愉悦感。
文章首发于公众号「架构师指南」及个人博客 shuyi.tech，欢迎关注访问。
什么时候重构？
什么时候重构？第一次只管去做，第二次会反感，第三次应该重构。事不过三，三则重构。
专门拨出时间重构是不可能的，我们需要在日常工作中不断地重构。但是还没开始有重复的功能，就想着重构，那太可笑了。但是重复的代码或者代码有问题，超过三次之后还不动手，那么就有点偷懒了。
什么时候不重构？
当现有代码根本不能正常运作的时候，你应该重写，而不是重构。
重构应该是一个习惯
重构应该是一种工作习惯，在日常工作中一点点重构，而不是妄想有专门的时间重构。我们曾经进行的一些大型重构，需要数月甚至数年的时间。如果需要给一个运行中的系统添加功能，你不可能让系统停止2个月去重构。你只能一点点地做你的工作，今天一点点，明天一点点。
如何测试？
我们的时间总是有限的，测试你最担心出错的部分，这样你能得到最大的收益。测试的时候，寻找边界条件，集中火力测试那里！
什么时候取消重构？
如果你感觉到重构失控了，那么最好的办法是取消重构，回到你的安全区去。等你重新能掌控的时候，再来做重构。
重构的团队意识
进行大规模重构时，有必要为整个开发团队建立共识。整个团队都必须意识到：有一个大型重构正在进行，每个人都应该相应地安排自己的行动。
设计模式帮助你重构
学习设计模式可以很好地帮助你重构，它能在适当的场合帮助你承载复杂的业务。但你不应该简单地了解，而是要多对比各个设计模式之间的区别，它们解决了什么问题，适用于什么场合。
技巧篇
不要出现重复代码
当出现重复代码时，你应该提取出公共方法。我想这个说得已经足够清楚了，当出现重复代码的时候就需要想想：我是否需要抽离出重复的代码？
不要出现过长、过短的函数
当函数过长，你应该根据业务逻辑提炼出多个函数。那一个函数多少行算是长呢？按我个人理解，一个函数在 20-50 行是比较合适的。但这也只是一个经验值，最根本的判断标准是：别人阅读你的代码的时候，是否能很清晰、很方便地读懂。 如果你写得很长，但是别人读得时候很舒服，那么也可以。
要注意函数过短也会带来阅读的困难，他会让你多次跳转，打断你的阅读思路。所以如果一个函数内容过短，你需要考虑是否去掉这个函数。简单地说，你还是应该根据业务逻辑结构化，将每块业务逻辑放到合适的函数中。
不要出现过大的类
当类过大，你应该考虑是否能拆分出多个类。或者你应该考虑，你的类抽象体系是否出现了问题。一个过大的类与过长的函数一样，会让人感觉到压抑、难于读懂。
不要让参数过长
当参数列过长，你应该使用对象参数。
提炼发散式变化
因为一个变化，而需要修改多个地方，这说明出现了发散式变化，你需要考虑将变动的代码合并在一起。
提炼对象
总是绑在一起出现的数据，需要把他们提炼到一个独立对象中。
引入解释性变量
不要让你的变量或表达式没有语义，必要时引入解释性变量。很多人会习惯性地用 flag 去承载一个表达式的值，但这并不是一个好的习惯。变量命名还是应该更加语义化，这样我们能更加清晰地明白这个变量的作用。
搬移函数
一个函数被另一个类调用得很频繁，那你可能得考虑把这个函数搬移到另一个类中。
搬移字段
一个字段被另一个类用得很频繁，或许你改考虑把这个字段搬移到另一个类中。
提炼类、简化类
某个类做了应该由两个类做的事情，此时应该提炼出一个新类，然后用组合关系组合起来。这其实与 SOLID 原则想契合，一个类应该是单一职责的，如果某个类做了两个类的事情，那说明其承担的职责就复杂了，因此需要抽离出一个新类出来。
而如果一个类并没有太多内容，这时候就应该考虑是否去掉这个类，优化整个类结构。
文章首发于公众号「架构师指南」及个人博客 shuyi.tech，欢迎关注访问。
参考资料
- 除旧迎新，试试《系统重构与迁移指南》 - 知乎
- 五个简单的原则，带你写出整洁代码 - 知乎
- GitHub - phodal/migration: 《系统重构与迁移指南》手把手教你分析、评估现有系统、制定重构策略、探索可行重构方案、搭建测试防护网、进行系统架构重构、服务架构重构、模块重构、代码重构、数据库重构、重构后的架构守护
- 技术债治理的四条原则 - ThoughtWorks 洞见
- 31 天重构指南 - InfoQ
- VIP！！！！Refactoring Day 1 : Encapsulate Collection · Los Techies
- 不要让 “Clean Code” 更难维护，请使用 “Rule of Three”-InfoQ
