敏捷开发智慧敏捷系列之三：做不做架构设计？

这是敏捷开发智慧敏捷的第三篇。（之一，之二，之三，之四，之五，之六）

缘起

甲：“敏捷不应该写架构设计，应该每个迭代都是相同的，才能达到自相似性（这是Ken Shweber说的）。”

乙：“如果不写架构设计，很容易返工，早晚还得重来。”

甲：“大不了重构，这是敏捷开发重要的实践。”

乙：“重构？重构的成本很高的，做几个迭代，后面重构都重构不过来了。”

甲：“架构设计写了很容易过度设计，而且在编码的时候还很容易全部推翻重来；。”

……

这个架构文档要不要写呢？写，为什么？不写，为什么？写，怎么写？不写，怎么不写？

为什么敏捷不做架构设计？

先把话说绝点，敏捷就是不写架构设计。那为什么不写架构设计？

还是为了减少浪费。

敏捷有两个理由认为写架构设计是浪费时间。

第一，业务需求是多变的。之前的架构写得再好，中间需求一变，架构还的改动，费时费力；很多需求可能是无用的，早期可能规划了，后期又会发现用不上，如果架构里边考虑了这些无用需求，就会过于庞大。

第二，架构设计很难判断是否正确、完备。这个本人也很有体会，本来以为很好的设计，到了编码的时候发现不是那么回事，这时候就得从头翻腾。评审一下如何？可惜，除了最终的软件，多数需求、架构、测试用例……都很难评审，评审半天，问题还是很多。

敏捷的这些假设，整体上非常普遍，可以说是在尝试“做好架构”而不得之后的妥协。

不在那些总是改来该去，还不知道是否可行的东西上浪费时间，是敏捷不做架构的出发点。

怎样写这个架构文档？

但是如果彻底不写架构设计，又可能返工，怎么办呢？当然是本着“最小浪费”原则来做架构设计。

下面是一些写和不写的内容：

写：相对稳定不变的，重构成本很高的，能看出对错的

不写：概念性的那不太准的，很容易扩展的，说不清对错的

具体要写什么不写什么，很大程度上要受到业务稳定性、技术的先进性、人员能力等各方面的影响。

所以，所有架构文档的所有写法，在每个企业都不相同，不应该问“敏捷开发应该怎样写架构文档？”，而是应该问“如果我的业务、技术、人员如此，应该怎样写架构文档？”，而若能这样发问，答案肯定可以自己找到了。

智慧敏捷的一个本质方法，是要去理解敏捷这样做的目的是什么，而不是敏捷应该怎样做。

倘若日后出现了先进的架构方法，或许架构就变成一种很容易做、很容易评审、很容易变动的东西，那时候就是另外一种说法了。但敏捷在架构设计这件事情上的本质目标却永远不变：减少浪费。

5分钟又到了，散会。