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