经历过大
规模架构重构（
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
。