经历过大 规模架构重构（ 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 的契机：
- 增加功能时， refactor 。
- Fix bug 时， refactor 。
- 进行 code review 时， refactor 。
最后，列 出 Martin Fowler 对于 refactor 的定义：
- Refactoring (noun) : a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.
- Refactor (verb) : to restructure software by applying a series of refactorings without changing its observable behavior.
最后，说 明一下，我对于 ReArchitecture 并不完全反对，合适的时机和情况下， 还是需要 ReArchitecture的，但只要秉持上述的原则和实践，可 以极大的避免无原则和无目的的 ReArchitecture 。