5W2H 分析法¶

3个知识点:

重构的目的（why）、对象（what）、时机（when）、方法（how）；
保证重构不出错的技术手段：单元测试和代码的可测试性；
两种不同规模的重构：大重构（大规模高层次）和小重构（小规模低层次）

Why¶

重构是时刻保证代码质量的一个极其有效的手段，不至于让代码腐化到无可救药的地步:

项目在演进，代码不停地在堆砌。
如果没有人为代码的质量负责任，代码总是会往越来越混乱的方向演进。
当混乱到一定程度之后，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本，
想要再去重构，已经没有人能做到了。

优秀的代码或架构不是一开始就能完全设计好的:

就像优秀的公司和产品也都是迭代出来的。
我们无法 100% 预见未来的需求，也没有足够的精力、时间、资源为遥远的未来买单，
所以，随着系统的演进，重构代码也是不可避免的。

重构是避免过度设计的有效手段:

在我们维护代码的过程中，真正遇到问题的时候，再对代码进行重构，
能有效避免前期投入太多时间做过度的设计，做到有的放矢。

重构对一个工程师本身技术的成长也有重要的意义:

重构实际上是对我们学习的经典设计思想、设计原则、设计模式、编程规范的一种应用
    重构实际上就是将这些理论知识，应用到实践的一个很好的场景，能够锻炼我们熟练使用这些理论知识的能力
    除此之外，将一个比较烂的代码重构成一个比较好的代码，会让你很有成就感
重构能力也是衡量一个工程师代码能力的有效手段
   初级工程师在维护代码，高级工程师在设计代码，资深工程师在重构代码

What¶

备注

根据重构的规模，我们可以笼统地分为大规模高层次重构（以下简称为 “大型重构”）和小规模低层次的重构（以下简称为 “小型重构”）。

大型重构:

指的是对顶层代码设计的重构，包括：
    系统、模块、代码结构、类与类之间的关系等的重构，
重构的手段有：
    分层、模块化、解耦、抽象可复用组件等等。
这类重构的工具就是我们学习过的那些设计思想、原则和模式。
这类重构涉及的代码改动会比较多，影响面会比较大，
    所以难度也较大，耗时会比较长，引入 bug 的风险也会相对比较大。

小型重构:

指的是对代码细节的重构，主要是针对类、函数、变量等代码级别的重构，比如:
    规范命名、规范注释、消除超大类或函数、提取重复代码等等。
小型重构更多的是利用编码规范。
这类重构要修改的地方比较集中，比较简单，可操作性较强，耗时会比较短，
    引入 bug 的风险相对来说也会比较小。
你只需要熟练掌握各种编码规范，就可以做到得心应手。

When¶

持续重构:

一条可持续、可演进的方式
像把单元测试、Code Review 作为开发的一部分，把持续重构也作为开发的一部分，
    成为一种开发习惯，对项目、对自己都会很有好处。

备注

重构能力很重要，但持续重构意识更重要。我们要正确地看待代码质量和重构这件事情。技术在更新、需求在变化、人员在流动，代码质量总会在下降，代码总会存在不完美，重构就会持续在进行。时刻具有持续重构意识，才能避免开发初期就过度设计，避免代码维护的过程中质量的下降。而那些看到别人代码有点瑕疵就一顿乱骂，或者花尽心思去构思一个完美设计的人，往往都是因为没有树立正确的代码质量观，没有持续重构意识。

How¶

小规模低层次的重构:

有时间，随时做。
可以借助静态代码分析工具（比如 CheckStyle、FindBugs、PMD），自动发现代码问题，
    然后针对性地进行重构优化。

大规模高层次的重构:

有组织、有计划，并且非常谨慎的，需要有经验、熟悉业务的资深同事来主导

提前做好完善的重构计划，有条不紊地分阶段来进行。
    每个阶段完成一小部分代码的重构，然后提交、测试、运行，
    发现没有问题之后，再继续进行下一阶段的重构，
    保证代码仓库中的代码一直处于可运行、逻辑正确的状态
每个阶段，我们都要控制好重构影响到的代码范围，
    考虑好如何兼容老的代码逻辑，必要的时候还需要写一些兼容过渡代码。
只有这样，我们才能让每一阶段的重构都不至于耗时太长（最好一天就能完成），不至于与新的功能开发相冲突。

意义:

对于重构这件事情，资深的工程师、项目 leader 要负起责任来，
没事就重构一下代码，时刻保证代码质量处在一个良好的状态。
否则，一旦出现 “破窗效应”

保持代码质量最好的方法还是打造一种好的技术氛围，以此来驱动大家主动去关注代码质量，持续重构代码。