在前一篇文章里面，我们分析了代码重构原则包括重构定义、重构时机以及中间层的扩展等内容，不过其中重构时机的解读，更多是侧重于宏观层面。在实际工作中，我们往往还需要更精确的衡量标准或者参考依据。
这里提到的衡量标准，Martin Fowler用了一个特殊的词来形容，就是“代码的坏味道”。
换个角度来看，代码的坏味道，也是代码需要重构的某种迹象、表现形式。这些“坏味道”，有的涉及具体的代码段，例如“重复代码”；有的涉及函数的组织形式，例如“过长函数”、“过长参数列”；也有涉及具体的类的设计，例如“过大的类”、“发散式变化”、“霰弹式修改”等。
其中每种坏味道，都会对应一个或者多个重构手法，并且在很多情况下，我们还需要结合具体情况，对问题进行细分，以找出更准确、更合适的解决方案。
结合个人理解与编程实践，这里挑选了部分可能更为常见的“代码的坏味道”与重构手法之间的对应关系加以汇总整理，具体可参考下面表格。
如果我们再换个角度，就会发现这些重构列表，要么是提升代码可读性、要么是改善代码的可维护性或者可扩展性；有的重构手法成本较低，花费的时间精力较少，有的则刚好相反，甚至于还有一些不在本列表中的大型重构。
——当项目处于前期，而整体时间预算并不怎么宽裕时，代码有重构的必要性，但也存在一定风险（时间风险加上改动波及影响），这时候应该如何处理？
这里提供一个参考思路：使用分支管理结合阶段性测试，同步进行。也即在原先的项目代码基础上，拉出单独分支用于代码重构，并且结合模块代码评审情况与重构列表，确定重构计划以及测试计划。更具体地，相关测试包括但不限于单元测试、集成测试。最终，我们可以根据时间进度与测试情况，评估当前重构成果在项目上的应用计划。
对于“代码的坏味道”及其重构手法，如果你有一些不同的看法或者心得体会，欢迎留言讨论。
延伸阅读：
