作者：張克強??? 作者微博：張克強-敏捷307

本實踐描述重點在于演進，本文通過以下方面來說明“演進”的架構。

1，?架構的范圍

2，?項目初次架構

3，?架構文檔

4，?迭代中的架構

5，?推遲決策的架構

6，?其它說明

?

明確架構的范圍

存在了有許許多多種架構，最著名的是與建筑和其他工程相關的。甚至在軟件工程領域，我們經常會遇到不同形式的架構。例如，除了軟件構架的概念，我們會遇到諸如企業架構，系統架構，組織架構，信息架構，硬件架構，應用架構，基礎設施架構等，每種類型都定義了一個架構的具體范圍。就算是在軟件架構范疇下，目前，軟件業界并沒有相互形式間的協定，所以導致了對軟件架構同一詞語的不同理解。軟件開發架構考慮的范圍隨著不同項目、不同團隊、項目的不同時間段而不同。

團隊考慮進行架構時，值得首先就架構的范圍進行討論，并達成初步的共識，當然架構范圍也不是從第一次達成共識后就不再變化，在架構演進時，團隊可以就架構范圍進行調整。

架構的范圍并沒有標準答案，下面是對于架構考慮范圍的推薦，最推薦的給5顆星，其次4、3、2。

·?支持的操作系統，比如?win7,?Redhat9???☆☆☆☆☆?

·?支持的數據庫?比如Oracle,?DB2,?Mysql?☆☆☆☆☆?

·?支持的瀏覽器（如果是有Brower訪問的）☆☆☆☆☆?

·?依賴的運行時環境?--比如Java,?Silverlight?☆☆☆☆☆?

·?依賴的中間件---?比如Java容器，tomcat,?websphere,?Tuxedo?☆☆☆☆☆?

·?依賴的核心構件或者Frame,?比如struts,?hibernate,?自定義的構件?☆☆☆☆☆?

·?層次劃分，比如?典型三層架構、多層架構??☆☆☆☆

·?識別進程，畫部署圖?☆☆☆☆☆?

·?劃分組件，畫組件圖?☆☆☆☆☆?

·?開發語言?比如c#,?java,?c++??☆☆☆☆☆?

·?開發所用的工具??比如IDE，報表設計器?☆☆☆☆?

·?重要組件間的接口?☆☆☆☆?

·?核心類的設計?☆☆☆?

·?數據庫設計?☆☆☆???（存儲數據和檢索有其特點。在表達方面有其自身的特點。如數據集的提取，運算等,?要注意性能，完整性等。數據庫設計也可做漸進設計）

·?核心流程的說明?☆☆?

·?部分核心類的類圖?☆☆??

·?特別的性能要求帶來的考慮?☆☆☆☆?

·?特別的可恢復性要求帶來的考慮?☆☆☆?

·?特別的信息安全要求帶來的考慮?☆☆☆

一般而言，架構范圍不包括需求細節、用戶交互細節、類的細節。

項目初次架構

項目很早的前期，比如第0次迭代，進行初次架構，團隊需要理解項目的現狀、范圍、特征。

對于架構，需要了解在架構關注的范圍內，哪些因素是硬性限制條件，哪些因素是可變限制條件，哪些因素是項目需要考慮解決的問題。一般地，全新開發項目的限制條件比較少，需要考慮解決的問題比較多。

所開發的系統將或者已經存在于環境中，那么其環境必然影響架構，所以需要考慮?“環境中的架構”。基本上，環境決定了系統運行的范圍，這些又約定和限制了架構。影響架構的環境的因素包含架構所支持的商務環境，系統涉眾群，內部技術限制（例如需要符合組織標準），和外部技術限制（例如對外部系統的接口或遵守外部規則的標準）。

在此期間，可以召開架構的頭腦風暴會議，討論系統的功能、性能等等特征，并思考實現這些特征的高層設計策略，甄別可行地技術策略。

根據這些了解、討論和思考，形成初始的架構文檔。

特別再次值得重復說明的是：多數的架構是在已有軟件或系統上進行的。原有軟件或系統將帶來原有的架構，這并不意味著新項目可以不再考慮架構。原有的架構可能不再適應當前的情況，而恰恰是需要改進的地方；原有的架構也許非常好，不必修改，新開發只需要在其指定的架構下按部進行即可；原有的架構也許總體可以，局部需要調整。總之，需要了解原有的架構。

架構文檔

在起草初始的架構文檔時，值得充分理解并復用原有架構方面的文檔。

無論利用原有文檔，還是新寫，應當形成一套架構文檔，說明團隊架構范圍內所關注的內容。這一套架構文檔要得到配置管理。

這套架構文檔的典型組成

1，?核心架構文檔（必需）

2，?接口文檔（可選）

3，?模塊或子系統架構（可選）

4，?其它補充說明（可選）

?

?

在迭代進行中，核心架構設計文檔始終保持是一個文件，這個文件隨著種種新情況、變更而得到演進，但始終保持完整性和全局性。

避免出現把新增修改的內容寫入特定版本號的架構文檔，進而導致組合多個文件才能反映架構整體情況。具體而言，避免如下情況：

假設在第2個迭代結束后已經?形成了?ABC架構文檔，在第3個迭代時，其中某部分有重要修改，?團隊為了明確這些是第3迭代的任務，也為方便的閱讀第3迭代的架構，把這部分修改另寫為第3迭代架構文件。在第4個迭代時，又有某部分需要新增修改，然后有出現了第4迭代架構文件，依此類推，到第10個迭代時，需要閱讀所有前面的架構文件才能了解全局，而不再有一份核心架構文檔就能反映全局。短期迭代的方便處理將損害長期的架構演進。

因此，演進的架構建議利用版本控制工具（比如CVS，SVN，ClearCase等）來管理架構文檔。

在項目進行的任何時間點，都能展現及時的一套架構文檔。

迭代中的架構

在后續的迭代中，在每個迭代的前期，考慮對于架構的影響，如果對于原有架構文檔有變化，就應當修訂架構文檔。在演進中，對于架構最常見的兩大影響是1，模塊的修改和新增；2由于時間推移所帶來的容量方面的問題，一般最突出的是性能問題。值得密切注意模塊之間的交互

推薦提問：

1，?這個迭代是否要新增模塊？

2，?是否對已經存在的模塊有修改，模塊之間的交互是否有變化？

3，?與其它系統的交互是否有變化？是否需要與新系統通訊？

4，?是否能夠支持容量方面的情況？比如訪問量？比如硬盤容量？帶寬？CPU？

?

另外可能變化方面是團隊對于架構范圍的理解可能變化，根據變化后的架構范圍理解，增補架構文檔的內容。

?

推遲決策的架構

在演進的架構中值得推遲決策，推遲決策并不是指到最后才決定做什么,而是要盡量推遲凍結的決策,以更靈活的應對不確定性。

當出現架構決策時，考慮如下提問：

·?現在需要制定這個決策嗎？

·?可以安全地推遲這一決策嗎？

·?能做些什么使決策可逆？

·?是否可以先進行些嘗試，以幫助決策？

?

在演進的架構下，也為決策的推遲提供了便利。當前迭代涉及的架構問題是需要馬上給出方案的，對于后續的架構問題是有機會推遲決策的。當然這里是有長期考慮和短期考慮的權衡，并不是說演進的架構下只需要考慮本迭代的架構問題，但也不是說需要考慮所有后續迭代的架構問題。

其它說明

在項目開始時，沒有必要安排超過迭代周期的、專門的架構設計階段或迭代。

在演進的背景下，預先花費大量時間的所謂設計階段是多余的。

-------------------

• 本文允許在知識共享 署名-相同方式共享 3.0協議和GNU自由文檔許可證下修改和再使用。

?

總結

以上是生活随笔為你收集整理的演进的架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。