重构与重写

随着时间的推移, 一个大型项目的代码会变得越来越糟. 我希望幸运地能找到例外, 但总体来说在大多数的项目中是如此. 原因很明显:

• 越来越多的特性. 这导致复杂度的增加.
• 捷径和权宜之计. 为了支持类似“我们在八月份需要这个花哨的搜索，没问题！(We need this fancy search till August. Period!)”的特性.
• 开发人员的轮换 新的开发人员并不知道所有架构背后的基本决定和想法. 知识也不可避免地随着人员的轮换而丢失。
• 开发团队的扩大 越来越多的人- 越来越少的沟通 – 坏的决定. 这导致代码重复, 和一些在缺乏基本条件的深刻理解等运行的hack代码

突然你不能很容易地添加新的功能，你不能轻易做出重大调整，你有沉重的技术负债，开发团队濒临崩溃。 你想改变这一点，只有两个选择：重构或一切从头开始重写。

 

重构和间断平衡

间断平衡是一个生物学理论，但它也被应用到其他复杂的自适应系统，像社会等。它指出，在相当长一段时期内系统几乎没有变化，然后非常迅速地变化。接着再次获得平衡。听起来很耳熟？ 是的，重构几乎是相同的过程。

任何对系统的改变在短时间内都会引入混乱。重构的目的的目标就是要消除混乱，但在刚开始时通常会加重混乱。当你正工作于改变时，你会让系统不是很稳定。但一旦改变结束系统就会更加有序。对于软件开发来说，这一条不总是对的。如果你使用了分支，会使改变更加安全。重大的改变也增加了引用新bug的风险。

重构真正的危险是局部最优(local optimums)。比起重构，完全重写你可以得到更好的架构。那怎么办呢？如果你有一个最终架构构想，利用它，试着做一个从当前的架构的到新架构的路线图。通常对简单的部分应该摆脱重构。

 

重写和混乱

当你从头开始重写时，不可避免会带了混乱，其中绝大部分很难预测最终结果。同样你有一个新的奇点(singularity)，将开创新的产品纪元。然而，你能确保会比以前的更好吗？在新产品版本中你要修复多少相同的bugs？

然而，重写也许看起来很快。我的意思是说你可以通过重写很快的发布一个新的版本，但多数是带有更多的bugs并且是不稳定的。

我认为我们可以预期到：

 

绿线显示了在重构中混乱的变化。每次重构后混乱的会有少量增加，但随着系统变得稳定混乱也减少了。你会很晚才看到的最终版本，但请记住，在这之前的多次版本发布会让客户较早地获得好处。

黑线是在全面重写中混乱如何变化。在重写时，旧系统还在那时，混乱没有变化。但公开发行后，混乱大幅度增加。可以想像不少新（老）bugs和怪异问题会出现，因此稳定期会更长 。但是，发布频率也会更快，原因是没有后顾之忧。例如，当你改变某个地方时你不需要支持所有的地方。但在重构时，需要保持系统在任何时候都是工作且稳定的，这就需要更多额外的工作量。

 

适应还是革命

可以从另一个角度来看这个问题。重构是适应，而全面重写是革命。同样，革命是一个混乱的猛兽。你可以选择慢慢地调整产品以适应新的外部条件下，或作一次革命重写。

 

因此，重写还是重构呢？

我觉得没有普遍正确答案来回答这个问题。如果面市时间非常重要，并且新版本在6个月内不能发布的话你会失去很多业务，您可以尝试完全重写。但是要充分考虑副作用！因为质量可能明显下降和需要很长时间达到稳定，这些都有可能损害现有的客户。

在大多数情况下重构是可取的。循序渐进，高品质，不断改进，满意的客户。我更喜欢它。但重写是如此的充满诱惑...

 

查看英文原文：Refactoring vs. Rewrite by Michael Dubakov