架構(gòu)之美第二章

兩個系統(tǒng)的比較，功能類似，但是結(jié)局不同。

這兩個系統(tǒng)特點(diǎn)有什么不同？是什么導(dǎo)致了不同的結(jié)局？

混亂大都市

特點(diǎn)：

微觀層面特點(diǎn)：

1. 沒有統(tǒng)一的概念將不同的部分組織起來
2. 代碼風(fēng)格不一致
3. 控制流無法預(yù)測，即控制流的流向很復(fù)雜
4. 額外的數(shù)據(jù)緩存，其目的讓數(shù)據(jù)停留在更方便的地方（但是，容易造成數(shù)據(jù)的不一致性，維護(hù)或擴(kuò)展不方便）
5. 沒有人了解整個系統(tǒng)，沒有任何文檔


宏觀層面特點(diǎn)：
1. 系統(tǒng)沒有彈性，無法變更和添加新功能
2. 版本周期過長，低品質(zhì)的軟件
3. 對第三方支持協(xié)議，涉及太多內(nèi)部結(jié)構(gòu)。會出現(xiàn)難以理解的、不容易復(fù)現(xiàn)的錯誤。
4. 團(tuán)隊新成員不理解整個系統(tǒng)，不能搞請狀況，流失率高

原因：

造成的惡果的原因：

1. 沒有清晰的需求。這個是項目開始之初，團(tuán)隊就不知道要構(gòu)建什么。這個是混亂的一個重要原因。

2. 系統(tǒng)結(jié)構(gòu)難以理解，壞的架構(gòu)設(shè)計只會招致更壞的設(shè)計（因為想解決問題，只能選用阻力最小的方法）

3. 缺乏內(nèi)聚，不相關(guān)的功能放在一起，沒有清晰的角色定義
4. 不必要的耦合。系統(tǒng)沒有最底層，沒有控制中心，所有組件必須一開始就創(chuàng)建。這使得代碼層次的測試不能進(jìn)行。

5. 沒有共同的代碼風(fēng)格，沒有共同的庫，沒有共同的命名習(xí)慣。重復(fù)的代碼到處被使用。

6. 開發(fā)周期過長，造成整個系統(tǒng)測試、迭代困難，軟件質(zhì)量沒有保證,這個即使惡果，又是原因之一

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

設(shè)計之城

而比較成功的設(shè)計，往往是一個持續(xù)的過程，不僅僅表現(xiàn)為幾個特征


如設(shè)計之城的各階段的特征：

在設(shè)計早期：

1. 確定了主要的功能領(lǐng)域，并推出初步架構(gòu)

2. 系統(tǒng)中各獨(dú)立部分的位置關(guān)系體現(xiàn)為傳統(tǒng)的分層結(jié)構(gòu)。并且，這些是基本的系統(tǒng)設(shè)計，可以隨功能模塊添加進(jìn)行擴(kuò)展。

3. 一些基本關(guān)注點(diǎn)的決定：
1） 頂層文件結(jié)構(gòu)
2） 如何對事物命名
3） 內(nèi)部"展示"風(fēng)格
4） 共同的編碼慣例
5） 選擇單元測試
6） 一些基礎(chǔ)設(shè)施的選擇（如版本控制、系統(tǒng)的構(gòu)建與持續(xù)集成）

在第二階段，功能擴(kuò)展：

1. 新代碼的定位
一開始就有系統(tǒng)結(jié)構(gòu)清晰的總體視圖，所以，新的功能單元可以添加到正確的功能區(qū)域，而不是為了一時方便，代碼隨意添加。（這樣，有的時候開發(fā)者的工作會需要動寫腦筋，但是在系統(tǒng)維護(hù)和擴(kuò)展時，就變得容易了）

2. 系統(tǒng)的一致性
頂層設(shè)計的良好風(fēng)格和決定，為底層代理好處，代碼是統(tǒng)一、整潔的。清晰的定義，確保沒有重復(fù)的代碼、接口慣例和常見設(shè)計模式被普遍使用、沒有特殊生命周期的對象和資源管理問題。（這個重點(diǎn)是在于減少功能重復(fù)）

3. 架構(gòu)增長
沒有什么是一層不變的，架構(gòu)應(yīng)該是方便擴(kuò)展、可重構(gòu)的。這樣，代碼可以快速增長，同時又保持好的內(nèi)部結(jié)構(gòu)，添加新的功能不是問題。

4. 延遲設(shè)計決定
這部分應(yīng)該是需求問題。YAGNI（如果不是馬上需要，就不要去做），早期只設(shè)計中要的部分，將余下的決定推遲。特別是，不確定的需求，需要猜測。

5. 保持品質(zhì)
結(jié)對編程、對代碼復(fù)審、單元測試。對不正確、不合適的變更都要拒絕。開發(fā)者需要對設(shè)計負(fù)責(zé)。

6. 技術(shù)債務(wù)管理
什么是技術(shù)債務(wù)？為了趕時間，對于不太重要的功能被砍掉，允許小的代碼"瑕疵"存在，發(fā)布時避免高風(fēng)險的改動。這些都應(yīng)該被標(biāo)記為技術(shù)債務(wù)。
應(yīng)該選擇合適的時間，及時集中清理這些技術(shù)債務(wù)，在后續(xù)版本中修改。

7. 單元測試 打造設(shè)計
單元測試在很大程度上定性了代碼設(shè)計，它迫使我們實現(xiàn)好的結(jié)構(gòu)，保證可測性。

8. 遵守設(shè)計
新的成員可以比較容易地拿起代碼開始工作。開發(fā)團(tuán)隊動態(tài)地遵守架構(gòu)設(shè)計，項目原則規(guī)定沒有人"擁有"某部分設(shè)計，而是所有人都應(yīng)該寫出高品質(zhì)的代碼，可以改動系統(tǒng)的所有地方。

未來：

1. 沒什么是一成不變的，在整潔的背景下，突出的技術(shù)爭論應(yīng)該被解決掉。著重于適應(yīng)性強(qiáng)的架構(gòu)和靈活的代碼結(jié)構(gòu)。

我自己遇到過的

好的系統(tǒng)架構(gòu)：

我看過一個導(dǎo)航引擎的架構(gòu)，這個一個好的架構(gòu)，是因為：

1. 軟件清晰的定義，分層的設(shè)計，功能劃分明確，各部分的依賴關(guān)系，數(shù)據(jù)通信方式確定。如Positioning, DestinationInput, Routing, Guidance, MapViewer等。

2. 代碼結(jié)構(gòu)清晰，功能模塊劃分后，對于底層和組件的關(guān)系進(jìn)一步分析，將結(jié)構(gòu)進(jìn)行分層設(shè)計。劃分出common，data access等公共部分。如此，代碼的文件結(jié)構(gòu)也比較清晰，每個模塊的文件夾下，有各自的頭文件與實現(xiàn)文件。

3. 外部接口與內(nèi)部實現(xiàn)盡量分離。所有外部接口部分的聲明都單獨(dú)放在一個文件中，而內(nèi)部結(jié)構(gòu)的聲明與實現(xiàn)放在其他文件中。如果是大部分模塊都使用的數(shù)據(jù)結(jié)構(gòu)，那就把它放入common層定義，在同一層內(nèi)的模塊間的數(shù)據(jù)結(jié)構(gòu)基本相互獨(dú)立，不同模塊的數(shù)據(jù)結(jié)構(gòu)盡量不相互引用（開發(fā)中會增加一些麻煩，但結(jié)構(gòu)上更清晰）。

4. 統(tǒng)一的框架和一些代碼生成工具。保證了內(nèi)部統(tǒng)一的風(fēng)格，編碼慣例。但是這些框架和工具也增加了入門的難度。

5. 保證單元測試，并且有一個完整的simulator，離線模擬器，replay模塊，保證了測試的及時性。

6. perforce，版本控制工具。


其他：
1. 基本沒有重復(fù)的代碼
2. 獨(dú)立的模塊，單元測試，迫使結(jié)構(gòu)走向高內(nèi)聚，低耦合的狀態(tài)。


另外一個，說不上是失敗的系統(tǒng)，但是有一些特點(diǎn)是明顯需要改進(jìn)的地方：
1. 對新成員，沒有完整的系統(tǒng)結(jié)構(gòu)文檔可以理解

2. 對于一個MVC式的結(jié)構(gòu)，數(shù)據(jù)傳遞要經(jīng)過很多層，特別是底層處理部分，新成員一般了解不到。如果一個模塊沒有完整的系統(tǒng)結(jié)構(gòu)說明，開發(fā)人員需要很久才能完整的了解這個模塊。
開發(fā)人員一般容易被一些類圖累到，而容易忽視底層或外在的數(shù)據(jù)/控制流向。

3. 重復(fù)的代碼隨意可見，為了及時完成業(yè)務(wù)邏輯，相同的代碼被復(fù)制粘貼。造成比較嚴(yán)重的技術(shù)債務(wù)。

其他比較大型的項目的通病：
1. 編寫比較復(fù)雜的結(jié)構(gòu)，并使用一些自制工具，這使得入門比較難。知其然不知其所以然。

總結(jié)

以上是生活随笔為你收集整理的架构之美-读书笔记之二的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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