敏捷開發智慧型敏二 做不做架構設計?

2021-09-01 11:01:29 字數 1256 閱讀 9933

[size=medium]

[b]緣起[/b]

甲:「敏捷不應該寫架構設計,應該每個迭代都是相同的,才能達到自相似性(這是ken shweber說的)。」

乙:「如果不寫架構設計,很容易返工,早晚還得重來。」

甲:「大不了重構,這是敏捷開發重要的實踐。」

乙:「重構?重構的成本很高的,做幾個迭代,後面重構都重構不過來了。」

甲:「架構設計寫了很容易過度設計,而且在編碼的時候還很容易全部推翻重來;。」

……這個架構文件要不要寫呢?寫,為什麼?不寫,為什麼?寫,怎麼寫?不寫,怎麼不寫?

[b]為什麼敏捷不做架構設計?[/b]

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

[b]還是為了減少浪費。[/b]

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

[b]第一,業務需求是多變的。[/b]之前的架構寫得再好,中間需求一變,架構還的改動,費時費力;很多需求可能是無用的,早期可能規劃了,後期又會發現用不上,如果架構裡邊考慮了這些無用需求,就會過於龐大。

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

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

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

[b]怎樣寫這個架構文件?[/b]

但是如果徹底不寫架構設計,又可能返工,怎麼辦呢?當然是本著「最小浪費」原則來做架構設計。

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

[b]寫:相對穩定不變的,重構成本很高的,能看出對錯的

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

[/b]

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

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

[b]智慧型敏捷的乙個本質方法,是要去理解敏捷這樣做的目的是什麼,而不是敏捷應該怎樣做。[/b]

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

[/size]

敏捷開發智慧型敏捷系列之三 做不做架構設計?

這是敏捷開發智慧型敏捷的第三篇。之一,之二,之三,之四,之五,之六 甲 敏捷不應該寫架構設計,應該每個迭代都是相同的,才能達到自相似性 這是ken shweber說的 乙 如果不寫架構設計,很容易返工,早晚還得重來。甲 大不了重構,這是敏捷開發重要的實踐。乙 重構?重構的成本很高的,做幾個迭代,後面...

敏捷開發智慧型敏捷系列之三 做不做架構設計?

甲 敏捷不應該寫架構設計,應該每個迭代都是相同的,才能達到自相似性 這是ken shweber說的 乙 如果不寫架構設計,很容易返工,早晚還得重來。甲 大不了重構,這是敏捷開發重要的實踐。乙 重構?重構的成本很高的,做幾個迭代,後面重構都重構不過來了。甲 架構設計寫了很容易過度設計,而且在編碼的時候...

敏捷開發智慧型敏捷系列之三 做不做架構設計?

這是敏捷開發智慧型敏捷的第三篇。之一,之二,之三,之四,之五,之六 甲 敏捷不應該寫架構設計,應該每個迭代都是相同的,才能達到自相似性 這是ken shweber說的 乙 如果不寫架構設計,很容易返工,早晚還得重來。甲 大不了重構,這是敏捷開發重要的實踐。乙 重構?重構的成本很高的,做幾個迭代,後面...