经历过大 规模架构重构( ReArchitecture )的同学都知道: ReArchitecture 是一个极其痛苦的过程,要想将原有的 working 的代码,彻底地用新的架构,新的技术 重新写一遍,其工作量是令人望而生畏的。最复杂的莫过于业务逻辑的梳理,如果你有精力将原有的代码从头读一遍,那是最 lucky 的事,但大多数情况下,别人写的代码 需要你自己重新写一遍,大多数人没有精力或不愿意去通读代码,而主要依赖于需求文档,结合旧代码,写出新的代码。但需求文档的更新永远赶不上代码的更新速 度,你得期盼原先写这个代码的同学有很好的习惯,将变更的需求反映在文档中,而且代码中有很好的注释。基本上这种情况很少见。
而且 ReArchitecture 的时间也相对较长,我经历过的 ReArchitecture 基本上都超过 30 个人月。而且多数需要 ReArchitecture 的系统都是重要的业务系统, ReArchitecture 意味着重构期间,业务逻辑不能有或基 本不能有太大的变化。这也是众多业务方不愿支持 ReArchitecture 的主要原因(因为从业务功能上基本是 无效果的)。多数 ReArchitecture 能够执行都是因为不改实在不行了,或 者是某项重要的业务功能不改无法实现,或是因为在现有的架构下实现业务功能的周期越来越长。
讲了这么 多 ReArchitecture 的缺点,但我们应该探究为什么要进行 ReArchitecture ?其本质的原因是什么?带着这个疑 惑,最近拜读了一些大师的文章,其中有 2 位的观点,对 ReArchitecture 的原因做了较清楚的说明。其中一位是 著名的 Martin Fowler ,在其《 Refactoring – Improving the Design of Existing Code 》书中对为何要做 refactor 做了如下的解释 (P55) :
“ 没有 refactor ,程序的设计就会 decay( 注:这个词不翻译,因为后面有一个类 似的词,翻了可能会引起歧义 ) 。当人们修改代码时, ( 修改代码以实现短期的业务目标或在没 有完全理解已有设计的情况下修改代码 ) 代码的结构就遭到了破坏。理解代码的 设计会变得非常困难。 Refactoring 有些像整理代码。即将那些不在合适位 置的代码移除。代码结构的破坏会有 cumulative effect 。当代码的设计越难理解,就越难保留 这种设计,其 decay 的速度就会越快,经常性的 refactor 可以帮助代码保持其设计 ”
看到这一 段(最好大家看看原文,会比我的翻译更原汁原味),觉得 Martin Fowler 讲的太精彩了,非常到位。同样的话 题, Netbeans 的首席架构师, Jaroslav Tulach 在其《 Practical API Design – Confessions of a Java Framework Architect 》一书也有更精准的描述 (P100) :
“ 架构的 degradation (这个词比 decay 更妙一些,我个人认为比 decay 更准确),即代码的各个部分开始和其 他不相关的部分互相 talking ,是不可避免的。一定会发生,除非主 动地预防 ”
原文很 少,引用如下:
“The degradation of architecture , where each part of the code base starts talking to each other unrelated part, is inevitable. It has to happen, unless explicitly prevented ”
但 Jaroslav Tulach ,认为解决之道是 module programming 。这个超出我要讨论的范围了,不展开 了。个人非常欣赏 Jaroslav Tulach 的这句话,也一直向周围的同事推荐这 句话。觉得精炼到了可以和文言文媲美的程度。而且讲出了解决之道:主动地预防 。这句话已经成为我考虑问题和设计方案时的一个重要原则了。
理解了 ReArchitecture 的原因之后,解决之道就变得比较容易 了,经常性地做一些 refactor 可以预防架构的 degradation 或代码的 decay 。关于怎么做 refactor ,在 Martin Fowler 的书中有全面的描述,这里我主要列出 refactor 的契机:
最后,列 出 Martin Fowler 对于 refactor 的定义:
最后,说 明一下,我对于 ReArchitecture 并不完全反对,合适的时机和情况下, 还是需要 ReArchitecture 的,但只要秉持上述的原则和实践,可 以极大的避免无原则和无目的的 ReArchitecture 。