【重构.改善既有代码的设计】13、重构，复用与现实

13、重构，复用与现实

 

为什么开发者不愿意重构他们的程序？

重构的好处是显而易见的，但这只是开发者的梦想，那么让梦想进入现实： 
为什么还不肯重构你的程序呢？有几个可能的原因： 
1. 你不知道如何重构。 
2. 如果这些利益是长远（才展现）的，何必现在付出这些努力呢？长远看来，说不定当项目收获这些利益时，你已经不在职位上了。 
3. 代码重构是一项额外工作，老板付钱给你，主要是让你编写新功能。 
4. 重构可能破坏现有程序。 
5. 如果你不是代码的唯一owner，怎么办？ 
6. 如果代码有多个分支，怎么办？

1、4可以技术解决，但2、3就到了人性层面了，尤其是当领导不支持的时候，坚持重构可能会让自己伤痕累累。

 

如何重构

如果已经确定要重构，那么下面就讲如何重构。

要满足如下两点： 
1、自动化支持 
2、安全

方案： 
1、自动化工具(如IDE等)可以帮上大忙。可以帮忙分析出代码的坏味道，可以有一些简单的自动重构功能，如重命名、提炼函数。 
2、设计模式可以帮忙。如果重构的目标是一个模式，那很幸运，至少模式是比较可靠的。

 

重构以求短期利益

1、消除重复后，只需要改一处地方了。 
2、让代码易读，易修改、易维护。

这里一个好的类比：重构就想锻炼身体，让代码保持健康。

 

降低重构带来的额外幵销（Reducing the Overhead of Refactoring）

· 目前已有一些工具和技术，可以使重构「快速」而「相对无痛苦」地完成。 
· 一些面向对象程序员的经验显示，重构虽然需要额外开销，但可以从它「在程序开发的其他阶段协助降低所需心力及滞怠时间」而获得补偿。 
· 尽管乍见之下重构可能有点笨拙、开销太大，但是当它成为软件开发规则的一部分，人们就不会再觉得它费事，反而开始觉得它是必不可少的。

 

安全地进行重构

所谓「安全重构」（safe refactoring）就是不会对程序造成破坏的重构。由于重构的意图就是在不改变程序行为的前提下修改程序结构，所以重构后的程序行为应该与重构前完全相同。

如何进行安全重构呢？你有以下数种选择： 
· 相信你自己的编码功力。 
· 相信你的编译器能捕捉你遗漏的错误。 
· 相信你的测试套件（test suite ）能捕捉你和编译器都遗漏的错误。 
· 相信代码复审（code review）能捕捉你、编译器和测试套件（test suite ）都遗漏的错误。

Martin 在他的重构原则中比较关注前三个选项。大中型公司则常常以代码复审作为前三个步骤的补充。

但，百密一疏，重构是人为的动作，人不可能万无一失。所以，如果你无法承担错误的后果，就不要重构了。