重构?还是重写?

  • Vikas Hazrati
  • 侯伯薇

2009 年 11 月 28 日

话题:敏捷重构架构文化 & 方法

重构和重写的目标,都是要通过提高的代码的可读性、结构和清晰性,从而提高系统的健壮性。清晰的代码更易于维护和改善。然而,在很多情况下,敏捷团队会难以在二者之间做出选择。

代码会随着时间的流逝变得越来越差,Michael Dubakov为此指出了下面的原因:

  • 越来越多的特性。它会导致复杂度的提升。
  • 捷径和权宜之道。为了支持诸如”我们在八月份需要这个 NB 的搜索,没二话”之类的特性
  • 开发者轮换。新的开发者根本不知道架构之后的所有起决定性作用的决定和主意。知识不可避免地随着人员的轮换而流失。
  • 开发团队的扩大。更多的人导致更少的交流,更少的交流产生糟糕的决定。

Michael 建议,虽然重构和重写都会使代码更加清晰,但是这两种技术都会导致现有系统的混乱。重构是一种增量式的活动,因此它每次只会接触到系统的一部分。这会在局部造成混乱,可能还比较容易控制。而另一方面,重写是更具有攻击性的改变,它会导致系统中更大的混乱。由于它会造成更广泛的影响,因此要想让重写的影响稳定下来,时间要比重构长得多。

我们重写旧的系统,因此混乱是家常便饭。在公开发行之后,混乱显著增长。我们预料会出现很多新的(和旧的)缺陷和古怪的行为,因此稳定期会更长

Peter Schuh认为团队经常会将两个词彼此替换使用,从而导致更多的迷惑和混乱。团队应该知道:和重构相比,重写更具有风险,因此应该恰当地使用术语。据他所说:

那只是语义上的。然而,在一些人受到伤害之前那只是语义上的。重写代码很有风险,并且有时会付出痛苦的努力,这么做不一定总有光明的结尾。如果我们执行重写,但是把它叫做重构,并且整个过程以梨形(指越到后来问题越多,需要付出的时间和成本也随之增长)进行,那就不会有业务人员停下来考虑语义了。他们只是会在下次听到重构这个词的时候退缩。

Guido A.J. Stevens 的想法很有趣,他认为问题并非出在重构和重写之间,而是在于:或者重构,或者重写并重构。他提出:即使当团队决定重写系统的时候,最终他们也会有两个系统并行运行。旧系统需要重构,而新系统正在被重写。这种组合变成了一项极度复杂的任务,据他所说:

维护老化的代码基础,并且编写新的系统,将会耗尽你的资源。你的团队被分割,并导致延迟。你需要制定计划,小心翼翼地执行转换。同时,你所面临的上市时间问题在你的竞争对手身上不存在,他们还会试图挖走你的客户。如果你能正视这种现实,并仍然想把公司前途押在重写上,那么你也许有机会成功。

Naresh Jain对于遗留代码有下面特别的的建议。当代码难于理解,并且团队不能确定它做什么的时候进行重构。当很清楚知道代码做什么,但是很难理解那些代码的时候就重写。

因此,重构是不断提升系统更好的方式。它是慢速前进的,通过小的、经常的提升来提高质量。重写也有其自身的优势,然而在很多情况下它是一种有风险的选择,并且团队可能永远都不确定产出物的情况。正如“Joel 说软件”中所说:

重要的是要记住,当你从零开始的时候,没有绝对的理由相信你会比你第一次做得好。

查看英文原文:Refactor or Rewrite?

敏捷重构架构文化 & 方法