作者：張克強(qiáng)??? 作者微博：張克強(qiáng)-敏捷307

本實(shí)踐描述重點(diǎn)在于演進(jìn)，本文通過以下方面來說明“演進(jìn)”的架構(gòu)。

1，?架構(gòu)的范圍

2，?項(xiàng)目初次架構(gòu)

3，?架構(gòu)文檔

4，?迭代中的架構(gòu)

5，?推遲決策的架構(gòu)

6，?其它說明

?

明確架構(gòu)的范圍

存在了有許許多多種架構(gòu)，最著名的是與建筑和其他工程相關(guān)的。甚至在軟件工程領(lǐng)域，我們經(jīng)常會(huì)遇到不同形式的架構(gòu)。例如，除了軟件構(gòu)架的概念，我們會(huì)遇到諸如企業(yè)架構(gòu)，系統(tǒng)架構(gòu)，組織架構(gòu)，信息架構(gòu)，硬件架構(gòu)，應(yīng)用架構(gòu)，基礎(chǔ)設(shè)施架構(gòu)等，每種類型都定義了一個(gè)架構(gòu)的具體范圍。就算是在軟件架構(gòu)范疇下，目前，軟件業(yè)界并沒有相互形式間的協(xié)定，所以導(dǎo)致了對(duì)軟件架構(gòu)同一詞語的不同理解。軟件開發(fā)架構(gòu)考慮的范圍隨著不同項(xiàng)目、不同團(tuán)隊(duì)、項(xiàng)目的不同時(shí)間段而不同。

團(tuán)隊(duì)考慮進(jìn)行架構(gòu)時(shí)，值得首先就架構(gòu)的范圍進(jìn)行討論，并達(dá)成初步的共識(shí)，當(dāng)然架構(gòu)范圍也不是從第一次達(dá)成共識(shí)后就不再變化，在架構(gòu)演進(jìn)時(shí)，團(tuán)隊(duì)可以就架構(gòu)范圍進(jìn)行調(diào)整。

架構(gòu)的范圍并沒有標(biāo)準(zhǔn)答案，下面是對(duì)于架構(gòu)考慮范圍的推薦，最推薦的給5顆星，其次4、3、2。

·?支持的操作系統(tǒng)，比如?win7,?Redhat9???☆☆☆☆☆?

·?支持的數(shù)據(jù)庫?比如Oracle,?DB2,?Mysql?☆☆☆☆☆?

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

·?依賴的運(yùn)行時(shí)環(huán)境?--比如Java,?Silverlight?☆☆☆☆☆?

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

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

·?層次劃分，比如?典型三層架構(gòu)、多層架構(gòu)??☆☆☆☆

·?識(shí)別進(jìn)程，畫部署圖?☆☆☆☆☆?

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

·?開發(fā)語言?比如c#,?java,?c++??☆☆☆☆☆?

·?開發(fā)所用的工具??比如IDE，報(bào)表設(shè)計(jì)器?☆☆☆☆?

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

·?核心類的設(shè)計(jì)?☆☆☆?

·?數(shù)據(jù)庫設(shè)計(jì)?☆☆☆???（存儲(chǔ)數(shù)據(jù)和檢索有其特點(diǎn)。在表達(dá)方面有其自身的特點(diǎn)。如數(shù)據(jù)集的提取，運(yùn)算等,?要注意性能，完整性等。數(shù)據(jù)庫設(shè)計(jì)也可做漸進(jìn)設(shè)計(jì)）

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

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

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

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

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

一般而言，架構(gòu)范圍不包括需求細(xì)節(jié)、用戶交互細(xì)節(jié)、類的細(xì)節(jié)。

項(xiàng)目初次架構(gòu)

項(xiàng)目很早的前期，比如第0次迭代，進(jìn)行初次架構(gòu)，團(tuán)隊(duì)需要理解項(xiàng)目的現(xiàn)狀、范圍、特征。

對(duì)于架構(gòu)，需要了解在架構(gòu)關(guān)注的范圍內(nèi)，哪些因素是硬性限制條件，哪些因素是可變限制條件，哪些因素是項(xiàng)目需要考慮解決的問題。一般地，全新開發(fā)項(xiàng)目的限制條件比較少，需要考慮解決的問題比較多。

所開發(fā)的系統(tǒng)將或者已經(jīng)存在于環(huán)境中，那么其環(huán)境必然影響架構(gòu)，所以需要考慮?“環(huán)境中的架構(gòu)”。基本上，環(huán)境決定了系統(tǒng)運(yùn)行的范圍，這些又約定和限制了架構(gòu)。影響架構(gòu)的環(huán)境的因素包含架構(gòu)所支持的商務(wù)環(huán)境，系統(tǒng)涉眾群，內(nèi)部技術(shù)限制（例如需要符合組織標(biāo)準(zhǔn)），和外部技術(shù)限制（例如對(duì)外部系統(tǒng)的接口或遵守外部規(guī)則的標(biāo)準(zhǔn)）。

在此期間，可以召開架構(gòu)的頭腦風(fēng)暴會(huì)議，討論系統(tǒng)的功能、性能等等特征，并思考實(shí)現(xiàn)這些特征的高層設(shè)計(jì)策略，甄別可行地技術(shù)策略。

根據(jù)這些了解、討論和思考，形成初始的架構(gòu)文檔。

特別再次值得重復(fù)說明的是：多數(shù)的架構(gòu)是在已有軟件或系統(tǒng)上進(jìn)行的。原有軟件或系統(tǒng)將帶來原有的架構(gòu)，這并不意味著新項(xiàng)目可以不再考慮架構(gòu)。原有的架構(gòu)可能不再適應(yīng)當(dāng)前的情況，而恰恰是需要改進(jìn)的地方；原有的架構(gòu)也許非常好，不必修改，新開發(fā)只需要在其指定的架構(gòu)下按部進(jìn)行即可；原有的架構(gòu)也許總體可以，局部需要調(diào)整。總之，需要了解原有的架構(gòu)。

架構(gòu)文檔

在起草初始的架構(gòu)文檔時(shí)，值得充分理解并復(fù)用原有架構(gòu)方面的文檔。

無論利用原有文檔，還是新寫，應(yīng)當(dāng)形成一套架構(gòu)文檔，說明團(tuán)隊(duì)架構(gòu)范圍內(nèi)所關(guān)注的內(nèi)容。這一套架構(gòu)文檔要得到配置管理。

這套架構(gòu)文檔的典型組成

1，?核心架構(gòu)文檔（必需）

2，?接口文檔（可選）

3，?模塊或子系統(tǒng)架構(gòu)（可選）

4，?其它補(bǔ)充說明（可選）

?

?

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

避免出現(xiàn)把新增修改的內(nèi)容寫入特定版本號(hào)的架構(gòu)文檔，進(jìn)而導(dǎo)致組合多個(gè)文件才能反映架構(gòu)整體情況。具體而言，避免如下情況：

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

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

在項(xiàng)目進(jìn)行的任何時(shí)間點(diǎn)，都能展現(xiàn)及時(shí)的一套架構(gòu)文檔。

迭代中的架構(gòu)

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

推薦提問：

1，?這個(gè)迭代是否要新增模塊？

2，?是否對(duì)已經(jīng)存在的模塊有修改，模塊之間的交互是否有變化？

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

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

?

另外可能變化方面是團(tuán)隊(duì)對(duì)于架構(gòu)范圍的理解可能變化，根據(jù)變化后的架構(gòu)范圍理解，增補(bǔ)架構(gòu)文檔的內(nèi)容。

?

推遲決策的架構(gòu)

在演進(jìn)的架構(gòu)中值得推遲決策，推遲決策并不是指到最后才決定做什么,而是要盡量推遲凍結(jié)的決策,以更靈活的應(yīng)對(duì)不確定性。

當(dāng)出現(xiàn)架構(gòu)決策時(shí)，考慮如下提問：

·?現(xiàn)在需要制定這個(gè)決策嗎？

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

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

·?是否可以先進(jìn)行些嘗試，以幫助決策？

?

在演進(jìn)的架構(gòu)下，也為決策的推遲提供了便利。當(dāng)前迭代涉及的架構(gòu)問題是需要馬上給出方案的，對(duì)于后續(xù)的架構(gòu)問題是有機(jī)會(huì)推遲決策的。當(dāng)然這里是有長(zhǎng)期考慮和短期考慮的權(quán)衡，并不是說演進(jìn)的架構(gòu)下只需要考慮本迭代的架構(gòu)問題，但也不是說需要考慮所有后續(xù)迭代的架構(gòu)問題。

其它說明

在項(xiàng)目開始時(shí)，沒有必要安排超過迭代周期的、專門的架構(gòu)設(shè)計(jì)階段或迭代。

在演進(jìn)的背景下，預(yù)先花費(fèi)大量時(shí)間的所謂設(shè)計(jì)階段是多余的。

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

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

?

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。