重构、重新架构、再设计与重写的区别

本文是翻译,版权归原作者所有


稍早的文章评论里,Jon Eaves表达了把重构做为动词过度使用的忧虑。尤其是重构(refactoring)【注1】和重新架构(rearchitecting)之间的界线非常模糊,重构被用作在你回头做第二遍的、任何行为的标签。你明白吗?Jon是对的。

被Martin Fowler定义的重构,是一个非常具体的术语,以数学上等同的具体术语为基础【注2】。重构是关于小的、“行为保留”的增加的、安全步骤。重构不是在应用程序里回头去“填充空白”的借口。

让我们给出一些具体的例子来说明什么不是重构,下面的行为都不被视作重构:

重构是“优化现有代码的设计”。在本文,优化意味着使之更加易于理解 和/或 更加灵活。下面的行为都被视作重构:

注意,我说的这些可以是重构的行为。决定它们是否属于重构的大部分因素在于你是如何去做的。重申:重构行为,是小而安全的步骤,最好是可逆的步骤。如果你不得不考虑它是否可以运行,那么它就不再是重构行为了。

那么如何区别重构与重新架构或再设计呢?重构是在键盘上完成的,接触真正的代码。而重新架构,最好是在白板上(或最近的酒吧)完成的。重新架构涉及了较大的愿景,考虑下一周/月/年的规划。重构是你用来帮助自己达成目标的技巧之一。

再设计(Redisigning)是一个术语,覆盖了任何时候你正在重新考虑的设计决定。由于敲代码是设计行为,甚至到了打字阶段,再设计肯定包含重构。毕竟,如果你不稍微再设计,就不太容易提高设计。然而,在通常情况,“再设计”意味着放弃老的解决方案,提出新的解决方案,或多或少地从头开始。如果你在白板上做再设计,可能是没问题的,与重新架构的举动类似,你仍然可以通过重构达成目标。如果你在键盘上完成再设计,这就不是重构了。

重写(Re-writing)类似再设计,不过它只是在键盘上完成。重写通常是受到了头痛的伤害,但是它常常让你丢掉惰性而到达一个更好的地方。类似拍卖和搬到了印度班加罗尔。

在实战中,会遇到混合的情况。重构应该是一个开发人员使用的日常进程的一部分,当你这样看的时候,界线会变得模糊。比如:

如果你最初开发了两个部件,后来才注意到公用的情况,该怎么办?好的,这是重构行为,可能要集中在以多态取代条件式的重构上。但是从外部看,这可能看起来非常像重写;必定(相对地)大量代码要消除掉。但是,不管你用什么方式削减,写第二个部件就不是一个重构行为。

重构更倾向于保持代码简单、灵活,而不是做对事情。做对事情经常涉及到添加新代码,或再设计应用程序的大块功能。使其灵活只是为了使其更加容易。这样说的话,重构最好被看做是一项赋能(enabling)行为。

如你所知,如果我写这篇文章不是在深夜,或许本文会更加连贯:) 如果你想更多了解重构,去看看Fowler的书。

译文:重构、重新架构、再设计与重写的区别 》| 腊八粥