架構設計策略之尋找設計的最佳平衡點

若是沒有所謂的「Deadline」（最後期限），咱們就不用擔憂架構設計的問題，由於咱們有足夠的時間去研究去學習找到最優的架構設計方案。然而，作夢是能夠有的。那怎麼尋找？相信你們都各有各的見解，基本分爲這幾派：

• 梭哈派，不要給我說什麼架構設計、設計思惟！老夫架構設計就是敲代碼，邊敲邊設計，天然而然代碼就是架構，想那麼多還不如直接敲。
• 借鑑派，善於借鑑業界成熟項目的標準，都按成熟標準來就好。
• 靈活派，根據實際項目需求來作架構設計，最好看現場狀況來判斷。
• 文檔派，都得寫文檔，寫完整了文檔，就能預防後續的問題和風險。

確定不止上面的介紹的對於架構設計的見解，相信你們都有本身認同的見解，歡迎評論區留下「最強流派」。

那架構設計的最佳平衡點確定會有架構大師作了研究的，下面將從專業的研究分析下。

架構設計對總工期的影響

參考Barry Boehm《Architecting: How Much and When?》書中項目工期的構成：開發、架構設計、返工（處理技術債：打補丁、改BUG、重構、重寫）（見圖2）。

可見，Boehm證實了隨着架構設計時間的增長，開發和返工量都會減小。書中還詳細地研究了系統規模影響最佳構架設計的平衡點，鑑於國內外的項目狀況不一樣，本文就不做爲參考了。但從中仍是能夠得出如下我的認爲比較客觀的結論：

• 系統越大，前期作架構設計的獲益越大，反之越小。
• 一千萬行代碼以上的大項目在總工期上架構設計時間佔3到4成較好，不超過一萬行代碼的小項目則不超過1成。
• 前期架構設計作得不夠，後期作好返工的心理準備。

架構設計的時間決定

上節內容用系統規模來評估架構設計的工做量彷佛很符合「靈活派」的作法，由於能夠根據項目需求很容易肯定系統的規模。相信確定有人會問：那複雜度不要考慮嗎？大型系統可能很複雜，但有「借鑑派」的成熟解決方案就沒必要作太多架構設計。然而，也並不是全部複雜度高的系統都很龐大。

所以，評估前期架構設計的時間，不能只按標準、經驗、代碼量、複雜度來決定。應該是按照風險來驅動架構設計（下篇文章再詳細講解），固然這也是Boehm作的研究（見《Using Risk to Balance Agile and Plan-Driven Methods》）。

總結

不管是如何尋找架構設計的最佳平衡點，都要遵循《架構設計思惟原則》和運用《架構設計思惟模式》來作架構設計，由於這些設計思惟原則和模式很是有助於實現風險驅動架構設計，找到架構設計的最佳平衡點。