首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 软件管理 > 软件架构设计 >

矫捷开发智慧敏二:做不做架构设计

2012-10-16 
敏捷开发智慧敏二:做不做架构设计?缘起甲:“敏捷不应该写架构设计,应该每个迭代都是相同的,才能达到自相似

敏捷开发智慧敏二:做不做架构设计?

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

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

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

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

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

……

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

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

还是为了减少浪费。

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

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

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

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

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

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

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

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

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

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

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

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

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

热点排行