目录
一.重构是什么(what)
重构(refactoring):在不改变代码外在行为的前提下，对代码作出修改，以改进程序的内部结构。
1.重构的本质
本质上说，重构就是在代码写好之后改进他的设计
传统开发过程中是先设计，再开发，更像是瀑布开发模式。
对重构来说，更像是敏捷开发模式，是一个设计与开发小步迭代，不断持续优化的过程。
2.重构≠性能优化
相似之处:
- 二者都需要修改代码;
- 二者都不会改变程序整体功能。
差异之处:
- 重构目的是让代码更容易理解和便于修改，重构后程序可能会运行的更快或者更慢;
- 性能优化只关心程序运行的更快，不关心代码的结构和可读性问题。
二.重构的目的(why)
目的:改善代码质量。
1.去写好的代码
什么是好的代码？
代码质量优劣并无绝对的判断标准，但是会有一些行业共同认可的标准。因为对于计算机来说，只要代码能运行，编译器不会在乎代码好不好看。但是代码是在实际开发应用中会涉及到修改，交接，是要给程序员和Leader去阅读的，一旦涉及到人，就会出现了代码的可读性问题。
好的代码的检验标准就是人们是否能轻而易举地修改它。
好代码应该直截了当，有人需要修改代码时，应该能轻而易举的找到修改点，应该能更快速做出修改，而不引入其他错误。
傻瓜都能写出计算机可以理解的代码，唯有能写出人类容易理解的代码，才是优秀的程序员。
让自己的代码更健康，而不是更完美
2.去写更灵活的代码
谁也无法预测未来的事。
对于一个团队来说，应对未来的发展，以及团队人员的变更，或者领导有了新的想法，每当遇到如此事件，我们的代码就要遭罪了。
灵活性可以更变通的应对不可预知的问题。
重构后的代码结构会更清晰，可以考虑预留一些功能接口，这样等到一个新同事拿到项目工程时，他会感谢上一位老哥的。
三.重构的时机(when and where)
1.何时重构
两种情况:开发过程中和开发完成后
- 重构的最佳时机就是在添加新功能之前。
最常遇到的情况是，待添加的新的功能也会用到之前使用的代码和数据结构，为了避免大量代码复制粘贴，消除重复代码，所以不要一直埋头苦干，而是要停下来多思考。
重构和添加新功能不能同时进行？
添加新功能时，就不应该修改既有代码，只管添加新功能;重构时就不再添加新功能，只管调整代码结构。同时进行二者会很混乱。
- 当代码读起来不明就里时
一旦需要思考“这段代码到底在做什么”，就要自问一下，“能不能重构这段代码，令其一目了然”。
- 有更合适的优化空间
此时代码可能能够被理解，但是写的很复杂或者有更好的优化，这种情况可以参考一些常见的优化方法，以及需要根据长期的开发项目经验来实施。
- 在开发项目管理中约定重构时机
通常在较为严谨的项目中，每一步都有自己的流程和时间限制，那么可以在项目管理中提前设置一些重构节点，有计划的安排重构工作，或者专门安排团队来做，定期的code review也是一个共同讨论重构的好时机。
2.何时不重构
不是所有情况都需要重构的，没必要为了重构而重构，以下情况就可以不考虑重构。
如果代码本身设计合理，质量过关，维护成本低，团队有着一套很稳定的管理流程，那么只要保持这样的状态就好，按照规则做好自己的事;
如果代码太烂了，并且耦合程度太高，重构的成本＞重写的成本，那么考虑升版代码，推倒重新设计;
如果代码本身已经运行了很多年，虽然凌乱，但是不影响运行，可以考虑把一些凌乱的代码打包隐藏到一个API中，以后不用管他即可;
重构的时机在实际工作中，要取决于整个项目的安排，或者对后续维护运行的影响，以及重构工作的人力成本和时间成本。从大领导的角度来说，通常只会关心交付的内容能不能满足合同要求，能不能结项结款。但是实际上从维护公司长期发展和培养个人程序开发优良喜欢来说，重构是领导层和基层人员都要时刻去考虑的。
四.重构的方法(how)
1.重构关键核心
开展高效有序的重构，关键心得是:小步快跑，保持代码处于永远可以工作的状态，小步修改积累起来也能大大改善系统的设计。
小步快跑:无论每次重构多么简单，重构后立刻运行测试，修改完成后提交版本控制，便于回滚。
2.重构方法
这部分内容是针对实际代码如何修改的实践方法，内容比较多，我会持续更新并通过单独链接的方式呈现，参考书中的js代码，我会做改成C++或者Python来重现，请根据需要自行跳转查看
3.重构工具
重构除了我们手动的修改代码，例如使用查找/替换方式去修改名字，目前的IDE中都自带一些自动化重构工具，比如JetBrains的IntelliJ IDEA，还有Eclipse，或者是微软的Visual Studio，都或多或少具备重构功能，有了这些工具我们可以更好的更方便的进行重构，但是重构的思路还是要人来自己设计和掌握。
小结
“重构的意义不在于把代码打磨的闪闪发光，而是纯粹的要从经济角度考量”
对于软件开发工作者来说，重构在实际工作中是由经济利益驱动的，如果只是做一锤子买卖，没人愿意去干重构这件事;或者本身不是你写的代码，你的领导突然让你把他重构，又不会额外给你什么好处;只有在跟你涉及利益相关时，比如你写的代码你后面还要维护它，或者你的团队在开发时就要求了一些管理流程，或者代码由多人协作，每个人都要清理出自己的接口，以防别人代码影响自己。
在学习或科研中也是一样的，代码更重要的是得到数据结果或者分析结果，你的论文中不会粘贴大量的代码。
所以不同的岗位，不同的情况，所要进行重构工作这件事的考量不同，但是重构也是一种习惯和素养，如果他成为你开发的一种良好习惯，你总有一天会从中受益的，毕竟谁都喜欢和能写出这样代码的人打交道，养成习惯，学到手，用不用，在哪里用，到时候再说。
参考书籍:
《重构:改善既有代码的设计(第2版)》
该文是参考了上面的内容，是一篇读书笔记及总结感悟，该书的参考语言是JavaScript，作者会用代码案例贯穿讲解，会涉及一些语法上的优化，有JS基础知识会更好理解。
本文不得用以任何商业活动，仅供学习使用。