这是敏捷开发智慧敏捷的第三篇。(之一,之二,之三,之四,之五,之六)

 

缘起

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

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

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

乙:“重构?重构的成本很高的,做几个迭代,后面重构都重构不过来了。”

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

……

这个架构文档要不要写呢?写,为什么?不写,为什么?写,怎么写?不写,怎么不写?

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

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

还是为了减少浪费。

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

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

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

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

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

怎样写这个架构文档?

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

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

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

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

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

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

 

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

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

 

5分钟又到了,散会。