关于代码重构的思考

什么是重构？

软件设计大师Martin Fowler是这样定义重构的：“重构是一种对软件内部结构的改善，目的是在不改变软件的可见行为的情况下，使其更易理解，维护成本更低。”因此，本质上来讲，重构就是不改变功能的前提下，改进软件的设计。

为什么要重构？

1.降低维护成本
项目在演进，代码在堆砌，这个过程中伴随着需求的变化、技术的更新、人员的流动，如果没有人关注代码的质量，代码一定会越来越混乱。当混乱到一定程度，量变引起质变，项目的维护成本很可能已经高过重新开发的成本。
2.设计缺陷
优秀的代码并不是一开始就完全设计好的，而是像优秀的产品一样不断迭代出来的，因为难以预见未来所有的需求，所以随着项目演进，重构不可避免。
3.避免过度设计
如果不希望在项目前期投入过多的时间、精力进行过度的设计，那么后期重构是一种有效的手段。

重构的时机？

如果项目代码质量烂到它的维护成本已经高过重新开发的成本，此时重构已经没有意义了，我们要避免这样的情况发生。因此要树立日常持续重构的意识，我认为这比重构的能力更重要。
下面推荐几个重构的时机：
1.开发新功能时重构
此时可能会发现很多问题，比如发现不同的类需要使用同一段代码，而这段代码在之前的一个类中；发现分支条件越来越多，难以维护；发现随着功能的增强，函数的参数列表越来越长，代码长度太长难以理解等。
2.修复问题时重构
比如接口，可能是接口的返回结果不符合预期，也可能是接口的性能达不到要求。
3.代码审查时重构
一般重要的项目都要通过代码审查才能上线。在代码审查阶段，代码审查人员可能对代码的可读性、可维护性、代码的性能等进行评价并给出建议。

如何重构？

实际工作中重构时，应该先分清楚重构的规模，是大规模还是小规模的重构，根据规模大小采取不同的重构策略。
大规模重构包括代码分层、模块化、解耦、梳理类之间的关系、抽象复用组件等，这部分工作比较抽象，一般需要利用一些设计思想、原则、模式。小规模的重构包括规范命名、注释、函数参数过多、消除超大类、提取重复代码等编程细节问题，这部分工作比较具体，更多的是利用相关编码规范。
大规模重构难度比较大，需要有组织、有计划地进行，分阶段地小步快跑，每个阶段完成一小部分代码的重构，然后提交、测试、运行，发现没有问题之后，再继续进行下一阶段的重构，保证代码仓库中的代码一直处于可运行、逻辑正确的状态。而小规模低层次的重构，因为影响范围小，改动耗时短，所以随时随地都可以去做，并且容易借助代码分析工具自动发现问题，有针对性的重构。