軟體架構要設計到什麼程度

由於軟體系統的複雜性，一般人很難非常清楚的將整個系統理的很清楚，所以才會出現架構視圖的概念，而架構視圖出現的一個主要動力或者原則就是：分而治之。

分而治之有兩種類型

1.      
按問題深度分而治之，即先不把問題想的那麼深入，那麼仔細，要淺嘗輒止。例如定義各個模組之間的介面就屬於這種，先不考慮如何?介面，只是定義模組之間進行通訊時的契約。

2.      
按問題廣度分而治之，即先不研究整個問題，而是研究問題的一部分，分割問題，各個擊破。例如採取MVC架構進行開發時，每一層都屬於一個比較深入的部分。

軟體架構應該採取哪種方式？

所謂架構設計，是關於如何構建軟體的一些最重要的設計決策，這些決策往往是圍繞著系統分為哪些部分，各部分之間如何互動進行展開的。

所謂詳細設計，則是針對每個部分的內部進行設計。

所以可以說對於架構設計，應該採取按照問題深度分而治之，關注的是系統的整體設計；而詳細設計時應該採取按照問題廣度分而治之，關注的是每個模組如何?。

軟體架構是團隊開發的基礎

一方面，架構從大局著手，就技術方面的重大問題作出決策，構造一個具有一定抽象層次的解決方案，而不是將所有細節全部展開，從而有效控制了‘技術複雜性’。

另一方面，因為架構中包含了關於各元素應該如何彼此互動的資訊，所以可以把不同的模組分配給不同的小組分頭開發，架構在中間扮演‘橋樑’和‘合作契約’的作用。

架構應該設計到什麼程度？

1.      
由於項目不同、Team Dev情況的不同，架構設計的程度也會不同。

2.      
軟體架構應該為開發人員提供足夠的指導和限制。

什麼是高來高去的軟體架構？

高來高去的架構是指不能為開發人員提供足夠的指導和限制的那種架構設計。

高來高去的架構的危害

1.      
缺少來自架構的指導和限制，開發人員進入開發階段後，會碰到很多問題，並且容易造成管理混亂，溝通和協作效率低。

2.      
對軟體品質非常關鍵的全域性設計決定被拖延到分頭開發期間草率決定，嚴重降低了軟體產品的品質。

3.      
沒有完成化解重大技術風險的職責，可能造成整個項目的失敗。

4.      
團隊成員對架構師意見很大，團隊士氣低落。

常見的高來高去的架構

1.      
缺失主要架構視圖。

越是複雜的系統，越是應該從多個方面進行架構設計。如果遺漏了對團隊某些角色的指導，那麼會對開發進度和開發品質造成眼中影響。如果存在這種現象，應該對遺漏的架構視圖進行設計。

2.      
淺嘗輒止，不夠深入。

對架構設計不夠深入，依然停留在概念階段。概念架構雖然‘有用’，但很多時候不是‘夠用’，很容易將重大技術風險遺留到後續開發中。如果存在這種現象，應該將設計決策必須細化到和技術相關的層面。

3.      
名不副實的分層架構。

指那些號稱採取分層架構，卻僅用分層來盡心職責劃分，而沒有規劃層次之間的互動介面和互動機制。如果存在這種現象，應該步步深入，明確各層之間的互動介面和互動機制。

參考文獻
《軟體架構設計》  溫昱