原文出处： @蛋疼的axb

假设你已经读过烂代码系列的前两篇：相识了什么是烂代码，什么是好代码，可是照旧不行制止的打仗到了烂代码（就像之前说的，险些没有措施员可以完全制止写出烂代码！）接下来的问题即是：如何应对这些身边的烂代码。

1.改进可维护性

改进代码质量是项大工程，要开始这项工程，从可维护性入手往往是一个好的开始，但也仅仅只是开始罢了。

1.1.重构的悖论

许多人把重构当做一种一次性举动，代码实在是烂的没法改了，可能没什么新的需求了，就召集一帮人专门拿出来一段时间做重构。这在传统企业开拓中几多能生效，可是对付互联网开拓来说却很难适应，原因有两个：

1. 互联网开拓考究快速迭代，假如要做大型重构，往往需要暂停需求开拓，这个根基上很难实现。
2. 对付没有什么新需求的项目，往往意味着项目自己已颠末尾成持久，纵然做了重构也带来不了什么收益。

这就形成了一个悖论：一方面那些改观频繁的系统更需要重构；另一方面重构又会延长开拓进度，影响改观效率。

面临这种抵牾，一种方法是放弃重构，让代码质量自然下降，直到工程的生命周期竣事，选择放弃可能重来。在某些场景下这种方法确实是有效的，可是我并不喜欢：比起让工程师不得不把天天的精神都挥霍在毫无意义的工作上，为什么不做些更有意义的事呢？

1.2.重构step by step

1.2.1.开始之前

开始改进代码的第一步是把IDE的重构快捷键设到一个顺手的键位上，这一步很是重要：抉择重组成败的往往不是你的新设计有何等牛逼，而是重构自己会占用几多时间。

好比对付IDEA来说，我会把重构菜单设为快捷键：

这样在我想去重构的时候就可以随手打开菜单，而不是用鼠标逐步去点，快捷键每次只能为重构节减几秒钟时间，可是却能明明淘汰工程师重构时的心理承担，后头会提到，小局限的重构应该跟敲代码一样属于日常开拓的一部门。

我把重构分为三类：模块内部的重构、模块级此外重构、工程级此外重构。分为这三类并不是因为我是什么分类强迫症，后头会看到对重构的分类对付重构的意义。

1.2.2.随时举办模块内部的重构

模块内部重构的目标是把模块内部的逻辑梳理清楚，而且把一个庞大无比的函数拆分成可维护的小块代码。大部门IDE都提供了对这类重构的支持，雷同于：

重定名变量

重定名函数

提取内部函数

提取内部常量

提取变量

这类重构的特点是修改根基会合在一个处所，对代码逻辑的修改很少而且根基可控，IDE的重构东西较量结实，因而根基没有什么风险。

以下例子演示了如何通过IDE把一个冗长的函数做重构：

上图的例子中，我们根基依靠IDE就把一个冗长的函数分成了两个子函数，接下来就可以针对子函数中的一些烂代码做进一步的小局限重构，而两个函数内部的重构也可以用同样的要领。每一次小局限重构的时间都不该该高出60s，不然将会严重影响开拓的效率，进而导致重构被无尽的开拓需求沉没。

在这个阶段需要对现有的模块增补一些单位测试，以担保重构的正确。不外以我的履向来看，一些简朴的重构，譬喻修改局部变量名称，可能提取变量之类的重构，纵然没有测试也是根基靠得住的，假如要在快速完成模块内部重构和100%的单位测试包围率中选一个，我大概会选择快速完成重构。

而这类重构的收益主要是提高函数级此外可读性，以及消除超大函数，为将来进一步做模块级此外拆分打好基本。

1.2.3.一次只做一个较模块级此外的重构

之后的重构开始牵扯到多个模块，譬喻：

删除无用代码

移动函数到其它类

提取函数到新类

修改函数逻辑

IDE往往对这类重构的支持有限，而且偶然会出一些莫名其妙的问题，（譬喻修改类名时一不小心把设置文件里的常量字符串也给修改了）。

这类重构主要在于优化代码的设计，剥离不相关的耦合代码，在这类重构期间你需要建设大量新的类和新的单位测试，而此时的单位测试则是必需的了。

为什么要建设单位测试？

一方面，这类重构因为涉及到详细代码逻辑的修改，靠集成测试很难包围所有环境，而单位测试可以验证修改的正确性。

更重要的意义在于，写不出单位测试的代码往往意味着糟糕的设计：模块依赖太多可能一个函数的职责太重，想象一下，想要执行一个函数却要模仿十几个输入工具，每个工具还要模仿本身依赖的工具……假如一个模块无法被单独测试，那么从设计的角度来思量，无疑是不及格的。