緣起

甲：“敏捷不應該寫架構設計，應該每個迭代都是相同的，才能達到自相似性（這是Ken Shweber說的）。”

乙：“如果不寫架構設計，很容易返工，早晚還得重來。”

甲：“大不了重構，這是敏捷開發重要的實踐。”

乙：“重構？重構的成本很高的，做幾個迭代，後面重構都重構不過來了。”

甲：“架構設計寫了很容易過度設計，而且在編碼的時候還很容易全部推翻重來；。”

……

這個架構文件要不要寫呢？寫，為什麼？不寫，為什麼？寫，怎麼寫？不寫，怎麼不寫？

為什麼敏捷不做架構設計？

先把話說絕點，敏捷就是不寫架構設計。那為什麼不寫架構設計？

還是為了減少浪費。

敏捷有兩個理由認為寫架構設計是浪費時間。

第一，業務需求是多變的

第二，架構設計很難判斷是否正確、完備。這個本人也很有體會，本來以為很好的設計，到了編碼的時候發現不是那麼回事，這時候就得從頭翻騰。評審一下如何？可惜，除了最終的軟體，多數需求、架構、測試用例……都很難評審，評審半天，問題還是很多。

敏捷的這些假設，整體上非常普遍，可以說是在嘗試“做好架構”而不得之後的妥協。

不在那些總是改來該去，還不知道是否可行的東西上浪費時間，是敏捷不做架構的出發點。

怎樣寫這個架構文件？

但是如果徹底不寫架構設計，又可能返工，怎麼辦呢？當然是本著“最小浪費”原則來做架構設計

下面是一些寫和不寫的內容：

寫：相對穩定不變的，重構成本很高的，能看出對錯的

不寫：概念性的那不太準的，很容易擴充套件的，說不清對錯的

具體要寫什麼不寫什麼，很大程度上要受到業務穩定性、技術的先進性、人員能力等各方面的影響。

所以，所有架構文件的所有寫法，在每個企業都不相同，不應該問“敏捷開發應該怎樣寫架構文件？”，而是應該問“如果我的業務、技術、人員如此，應該怎樣寫架構文件？”，而若能這樣發問，答案肯定可以自己找到了。

智慧敏捷的一個本質方法，是要去理解敏捷這樣做的目的是什麼，而不是敏捷應該怎樣做。

倘若日後出現了先進的架構方法，或許架構就變成一種很容易做、很容易評審、很容易變動的東西，那時候就是另外一種說法了。但敏捷在架構設計這件事情上的本質目標卻永遠不變：減少浪費。