降低代码重构的风险

重构是每一个开发人员都要面对的功课，Martin Fowler将其定义为“在不改变软件外部行为的前提下，对其内部结构进行改变，使之更容易理解并便于修改”。技术专家Paul在博客中讨论了重构的风险，并提出了降低风险的措施。

\u0026#xD;\n

Paul在文中指出：

\u0026#xD;\n

\u0026#xD;\n

重构代码是危险的，代码的变化会导致测试的压力很大。除非有必要的理由，否则不要轻易重构。我指的重构并不是说把while循环改成for循环，或者把StringBuffer改成StringBuilder，而是指比较大的改动，比如重新方法、函数或者整个类或者包。

\u0026#xD;\n

\u0026#xD;\n

错误的重构时机包括：

\u0026#xD;\n

• 代码逻辑对你来说过于复杂，而且没有时间去分析它。\u0026#xD;\n
• 你没有理解为何之前的开发人员是这样编写代码的。\u0026#xD;\n
• 你参与的系统是关键系统，而且时间紧。\u0026#xD;\n
• 你对团队、应用或者编程语言是新手。\u0026#xD;\n

正确的重构时机包括：

\u0026#xD;\n

• 现有的代码比预期的要复杂，而且你已经分析过它。\u0026#xD;\n
• 你所做的改动比现有代码逻辑更加清晰。\u0026#xD;\n
• 你有时间、人力和财力来增加完整的项目回归测试。\u0026#xD;\n
• 现有代码过时了而且效率低下，比如孤立的或者质量差的代码。\u0026#xD;\n
• 你和同事讨论过重构代码的好处和风险，并且达成一致。\u0026#xD;\n

如何减低重构风险呢？Paul认为可以从以下几点入手：

\u0026#xD;\n

• 利用自动化的回归测试来快速验证你的代码更改，这非常重要，如果你还没有准备好自动化回归测试，那么请在重构之前先搭建好测试环境。\u0026#xD;\n
• 努力把代码的重构安排在较小的开发周期内。\u0026#xD;\n
• 尽量把更改独立化，方便查找问题。\u0026#xD;\n
• 确保测试计划包含了所有的回归、功能、负载、性能和用户验收测试。\u0026#xD;\n
• 在开始重构之前，花时间弄清楚复杂的代码逻辑。\u0026#xD;\n
• 在需要时利用设计模式，不要为了用而用，必须要充分的理由。\u0026#xD;\n

无独有偶，技术专家McConnell在“代码大全”中也提到了安全重构的措施。

\u0026#xD;\n

\u0026#xD;\n

保存初始代码——在开始重构之前，要保证你还能回到代码的初始状态。用版本控制系统保存一个初始版本，或者把最初正确的文件复制到备份目录中去。

\u0026#xD;\n

重构的步伐请小一些——这样才能理解所做修改对程序的全部影响。

\u0026#xD;\n

同一时间只做一项重构——除非是对付那些最为简单的重构，否则请在同一时间只做一项重构，在进入下一项重构之前，对代码重新编译并测试。

\u0026#xD;\n

把要做的事情一条条列出来——伪代码编程过程的自然延伸就是列出一份重构列表，然后你应该按照这份列表从A点一步步走到B点。写一份重构列表能够让你在修改时保持思路连贯。

\u0026#xD;\n

多使用检查点——在重构的时候，很容易出现代码没有按照设想正常运行的情况。除了保存初始代码外，在重构中还应在多个地方设置检查点，这样一来，即使你编码时钻进了死胡同，仍然可以让程序回到正常工作的状态。

\u0026#xD;\n

利用编译器警告信息——要让一些小错误错过编译器的目光很容易。你最好把编译器的警告级别设置为尽可能苛刻，一旦输入中有这些小错误，编译器就能立刻把它们找出来。

\u0026#xD;\n

重新测试——应该把重新测试作为检查所修改代码工作的补充。当然，这点要取决于从一开始你是否就有一套优秀的测试用例。

\u0026#xD;\n

增加测试用例——除了重新运行过去做过的那些测试，还应该增加新的单元测试来检验新引入的代码。如果重构使得一些测试用例已经过时，那么就删除这些用例。

\u0026#xD;\n

根据重构风险级别来调整重构方法——有一些重构实施起来会比其他重构更为危险。而类似于“用具名常量替代神秘数值”一类的重构则机会不会出现什么问题。涉及到类、成员函数结构、数据路架构等改变，或者对布尔判断等进行修改的重构则极具风险。对于简单的重构而言，你只需要简化整个重构过程，然后简单的对代码重新测试，而不用一次去完成一个重构，也不用进行正式的检查工作。

\u0026#xD;\n

\u0026#xD;\n

不适合重构的情况包括：

\u0026#xD;\n

\u0026#xD;\n

不要把重构当做先写后改的代名词——重构最大的问题在于被滥用。程序员们有时会说自己是在重构，而实际上他们所完成的工作仅仅是对无法运行的代码修修补补，希望能够程序跑起来。重构的含义是在不影响程序行为的前提下改进可运行的代码。那些修补破烂代码的程序员们不是在重构，而是在拼凑代码。

\u0026#xD;\n

避免用重构代替重写——有时，代码所需要的不是细微修改，而是直接一脚踢出门外，这样你就可以全部重新开始。如果发现自己处于大规模的重构之中，就应该问问自己是否应该把这部分代码推到重来，重新设计，重新开发。

\u0026#xD;\n

\u0026#xD;\n

Kent Beck也认为，重构中面临最大的挑战就是如何做到循序渐进，循序渐进指的是如何将工作分解为可控的步骤，并且每个步骤都易于管理。重构步伐过快会导致不稳定代码的出现。此外，想得越多，越是谨慎反而会严重减慢重构的步伐。

\u0026#xD;\n

\u0026#xD;\n

正如许多与我结对编程的伙伴都会告诉你的那样，我有一个非常不招人喜欢的习惯：在重构时总会说“不要再想啦”。我知道这并不是我真正要说的，因为我不可能去故意表达这个意思，但是直到现在，我才有机会可以给出一个更好的解释。

\u0026#xD;\n

\u0026#xD;\n

垂直重构是指调整方法或代码块在调用堆栈中的上下顺序，然而水平重构则指的是在类似于同级别的对象间所做的调整。依Kent所述，重构时应避免同时做上述两种调整。

\u0026#xD;\n

\u0026#xD;\n

当需要重构具有多重调用或是多重实现的对象时，就要额外小心，并且重新回到垂直和水平方法，将这两者操作分开进行，并且要时刻注意代码重构的深度。

\u0026#xD;\n

\u0026#xD;\n

Kent Beck认为比较好的一个办法就是使用索引卡（Index Cards）：

\u0026#xD;\n

\u0026#xD;\n

在电脑旁放置索引卡会帮助我保持专注。当我在处理水平重构时突然意识到还可以做垂直重构时，我会迅速记在索引卡上，然后马上回到刚才正在进行的工作中。这种方法不仅可以使我在进行下一步工作前，有效地先将手头的工作结束，同时，又不会导致某些好点子被遗忘。方法之好用，整个过程感觉就像是在做冥想，技能感受到自己的呼吸，又不会被完全自我的意识所牵绊。

\u0026#xD;\n

\u0026#xD;\n

InfoQ的读者对代码重构有何见解？欢迎发表自己的看法！