《軟體架構設計》閱讀

1，轉自 百度百科 “MVC模式”：

http://baike.baidu.com/view/739359.htm

 

2，關鍵需求決定架構

軟體架構師沒有時間對“所有需求”進行深入分析，這是現實——大多數項目都面臨項目工期的壓力，軟體架構師必須在一定的時間內定奪架構設計方案；否則，沒有軟體架構所提供的對技術的足夠指導以及對分工協作的足夠限制，後期的團隊開發將面臨巨大風險。

軟體架構師沒有必要對“所有需求”進行深入分析，這是策略——把大部分時間和精力花在對決定架構最重要的一部分需求上，好鋼用在刀刃上，最終你設計出的軟體架構的品質反而會更高；否則，所有需求的分析都不夠深入，導致最終設計出的軟體架構可能會流於形式。

 

3，關鍵性的第一步是縮小範圍

PeopleSoft公司的首席技術官Rick Bergquist說得精闢：“我的第一個老闆John Grillos曾說過，要擇戰而鬥。擇戰的標準如下：它們要具有重要性，它們要具有可能性，它們的數量要少。”

 

4，實踐中的常見問題

問題一：抱怨留給架構設計的時間太短，而不是接受項目節奏普遍加快的現實。

從根本上講，這是沒有意識到軟體開發所根植於的業務背景——當然，我相信或多或少也受到瀑布模型的影響。無論是對於企業業務還是個人業務，在複雜和高速變化的經濟環境裡，在對手雲集的競爭條件下，軟體系統“上馬”太慢本身就潛藏著巨大風險。在《非程式員》第50期中有一篇來自Markus Völter和Jorn Bettin的論文《模型驅動軟體開發模式》，其中強調新的商業應用的開發期最多不得超過9個月：

……

每三個月至少要提供可交付代碼。

理想情況下，每三個月應將代碼部署到產品中，並得到實際反饋。

新的商業應用的開發，必須在九個月之內“哇哇墜地”，否則就可能危及“媽媽”（開發組）或“嬰兒”（應用）的生命……

 

 

問題二：認為必須詳細分析所有的需求，只有這樣才能設計出滿足所有需求的軟體架構。

有仗就打、有人討敵罵陣就出戰，這種情形在曆史小說裡經常見到，但往往出現在有勇無謀的武將身上。與此類似，想要將所面對的所有需求都分析一遍的軟體架構師是否想過：這是否現實？在有限的時間裡，將精力分散在過多的問題上，其結果往往是效果更差。

我們的策略是：關鍵需求決定架構，其餘需求驗證架構。

順著“全面認識需求”的策略思考開去，很容易讓人產生疑問：你是在說瀑布式開發嗎？當然不是。我們的策略是：在架構設計期間，關鍵需求決定架構，其餘需求驗證架構。也就是說，“關鍵需求決定架構”和“全面認識需求”的策略是不矛盾的。

非關鍵需求可以用來驗證架構，比如以架構方案評審的方式，從每項非關鍵需求的角度對架構方案進行走查。

 

 

問題三：認為軟體架構必須是完美的技術解決方案。

關於這一點，Philippe Kruchten在他的論文《Common Misconceptions about Software Architecture》中明確地進行了批評，並指出架構“夠用就好”：

通常，在進行系統架構設計時，時間非常關鍵。架構師根本沒有時間去系統地研究每一種可能的解決方案，以找出最佳解決方案；而是必須快速決策，以便讓軟體開發工作進行下去。項目開發就像一場“戰鬥”，如果慢慢吞吞地研究出了最佳解決方案，只怕整場“戰鬥”早已結束多時了，這顯然毫無意義。我經常這樣描述架構師的工作：在有些事情並未完全清楚的情況下，快速做出一系列並不算完美的設計決策。架構並不是靜態功能，因此無法最佳化至最佳——無論是設計約束，還是棘手問題，都不會長時間不變而“等”你找到最佳方案。架構不是要完美，而是要足夠滿意。（Usually, time is of the essence when designing system architectures. The architects have no latitude to systematically study all possible solution paths and their combinations in order to come up with the optimal solution; they must rapidly make decisions to allow work to proceed. There is no point in coming up with the ideal solution after the battle is lost. I often describe the life of a software architect as a long and rapid succession of suboptimal design decisions taken partly in the dark. It is not a static function that we are optimizing anyway. Neither the constraints nor any parts of the problem are static enough for long enough to approach anything "optimal". Architecture is not about the optimal, or ideal; it is about the adequate, or satisfactory.）

 

5，如何確定關鍵需求——需求的優先順序

對軟體架構關鍵的需求包括功能需求、品質（屬性）需求、商業需求三類。

所謂對軟體架構關鍵的功能需求，就是它涉及（或串起）的模組最多、最典型的功能需求。

對架構至關重要的品質屬性需求是那些經過權衡取捨、最終決定重點支援的品質屬性需求。