重构代码（设计模式）

定义

重构不改变外界行为的可见行为。我们可以把重构理解为在保持功能不变的前提下，利用设计思想，设计原则，模式，编程规范等理论来优化代码，修改设计上的不足，提高代码的质量。

为什么要重构代码

重构是时刻保证代码质量的一个极其有限的手段，不至于让代码坏到无可救药的地步。项目在演进，代码在不停的堆砌。如果没有人为代码的质量负责，代码总会往越来越混乱的地方演进。当混乱到一定程度的时候，两边引起质变。项目维护成本已经搞过重新开发一套新的代码的成本。想要去重构已经没有人能够做到了。

其次优秀的代码不是一开始就能完全设计好的。就像优秀的共色和产品都是迭代出来的。我们无法遇见100%的需求，也没有足够的时间资源为遥远的未来买单。所以代码的重构是不可避免的。

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

重构实际上是我们学习经典设计思想，设计原则，设计模式，编程范式的一种应用。重构也是衡量一个工程师的有效的手段。所谓初级的工程师维护代码。高级的工程师设计代码。资深的工程师重构代码。这句话的意思初级工程师在自己已有的框架下，修改bug .修改添加功能。高级工程师从0开始设计代码结构，搭建代码框架。而资深的工程师为代码的质量负责。需要发掘代码存在的问题。重构代码。时刻保证代码在一个可控的状态。

到底重构什么

包括系统，模块，代码结构，类与类之间的关系。重构的手段有分层，模块化，解耦，抽象。小型的重构，有命名规范，规范注释，消除超大类，超大函数，提取重复的代码。这种重构比较集中，比较简单，可操作性比较强，耗时比较短。引入bug 的风险也比较小。你需要熟练掌握各种编程规范。

什么时候重构代码

搞清楚了为什么重构，到底重构什么，我们再来看一下，什么时候重构？是代码烂到一定程度之后才去重构吗？当然不是。因为当代码真的烂到出现“开发效率低，招了很多人，天天加班，出活却不多，线上 bug 频发，领导发飙，中层束手无策，工程师抱怨不断，查找 bug 困难”的时候，基本上重构也无法解决问题了。我个人比较反对，平时不注重代码质量，堆砌烂代码，实在维护不了了就大刀阔斧地重构、甚至重写的行为。有时候项目代码太多了，重构很难做得彻底，最后又搞出来一个“四不像的怪物”，这就更麻烦了！所以，寄希望于在代码烂到一定程度之后，集中重构解决所有问题是不现实的，我们必须探索一条可持续、可演进的方式。所以，我特别提倡的重构策略是持续重构。这也是我在工作中特别喜欢干的事情。平时没有事情的时候，你可以看看项目中有哪些写得不够好的、可以优化的代码，主动去重构一下。或者，在修改、添加某个功能代码的时候，你也可以顺手把不符合编码规范、不好的设计重构一下。总之，就像把单元测试、Code Review 作为开发的一部分，我们如果能把持续重构也作为开发的一部分，成为一种开发习惯，对项目、对自己都会很有好处。尽管我们说重构能力很重要，但持续重构意识更重要。我们要正确地看待代码质量和重构这件事情。技术在更新、需求在变化、人员在流动，代码质量总会在下降，代码总会存在不完美，重构就会持续在进行。时刻具有持续重构意识，才能避免开发初期就过度设计，避免代码维护的过程中质量的下降。而那些看到别人代码有点瑕疵就一顿乱骂，或者花尽心思去构思一个完美设计的人，往往都是因为没有树立正确的代码质量观，没有持续重构意

如何重构代码

前面我们讲到，按照重构的规模，重构可以笼统地分为大型重构和小型重构。对于这两种不同规模的重构，我们要区别对待。对于大型重构来说，因为涉及的模块、代码会比较多，如果项目代码质量又比较差，耦合比较严重，往往会牵一发而动全身，本来觉得一天就能完成的重构，你会发现越改越多、越改越乱，没一两个礼拜都搞不定。而新的业务开发又与重构相冲突，最后只能半途而废， revert 掉所有的改动，很失落地又去堆砌烂代码了。在进行大型重构的时候，我们要提前做好完善的重构计划，有条不紊地分阶段来进行。每个阶段完成一小部分代码的重构，然后提交、测试、运行，发现没有问题之后，再继续进行下一阶段的重构，保证代码仓库中的代码一直处于可运行、逻辑正确的状态。每个阶段，我们都要控制好重构影响到的代码范围，考虑好如何兼容老的代码逻辑，必要的时候还需要写一些兼容过渡代码。只有这样，我们才能让每一阶段的重构都不至于耗时太长（最好一天就能完成），不至于与新的功能开发相冲突。大规模高层次的重构一定是有组织、有计划，并且非常谨慎的，需要有经验、熟悉业务的资深同事来主导。而小规模低层次的重构，因为影响范围小，改动耗时短，所以，只要你愿意并且有时间，随时都可以去做。实际上，除了人工去发现低层次的质量问题，我们还可以借助很多成熟的静态代码分析工具（比如 CheckStyle、FindBugs、PMD），来自动发现代码中的问题，然后针对性地进行重构优化。对于重构这件事情，资深的工程师、项目 leader 要负起责任来，没事就重构一下代码，时刻保证代码质量处在一个良好的状态。否则，一旦出现“破窗效应”，一个人往里堆了一些烂代码，之后就会有更多的人往里堆更烂的代码。毕竟往项目里堆砌烂代码的成本太低了。不过，保持代码质量最好的方法还是打造一种好的技术氛围，以此来驱动大家主动去关注代码质量，持续重构代码。