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