架構之美第二章

兩個系統的比較，功能類似，但是結局不同。

這兩個系統特點有什么不同？是什么導致了不同的結局？

混亂大都市

特點：

微觀層面特點：

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


宏觀層面特點：
1. 系統沒有彈性，無法變更和添加新功能
2. 版本周期過長，低品質的軟件
3. 對第三方支持協議，涉及太多內部結構。會出現難以理解的、不容易復現的錯誤。
4. 團隊新成員不理解整個系統，不能搞請狀況，流失率高

原因：

造成的惡果的原因：

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

2. 系統結構難以理解，壞的架構設計只會招致更壞的設計（因為想解決問題，只能選用阻力最小的方法）

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

5. 沒有共同的代碼風格，沒有共同的庫，沒有共同的命名習慣。重復的代碼到處被使用。

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

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

設計之城

而比較成功的設計，往往是一個持續的過程，不僅僅表現為幾個特征


如設計之城的各階段的特征：

在設計早期：

1. 確定了主要的功能領域，并推出初步架構

2. 系統中各獨立部分的位置關系體現為傳統的分層結構。并且，這些是基本的系統設計，可以隨功能模塊添加進行擴展。

3. 一些基本關注點的決定：
1） 頂層文件結構
2） 如何對事物命名
3） 內部"展示"風格
4） 共同的編碼慣例
5） 選擇單元測試
6） 一些基礎設施的選擇（如版本控制、系統的構建與持續集成）

在第二階段，功能擴展：

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

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

3. 架構增長
沒有什么是一層不變的，架構應該是方便擴展、可重構的。這樣，代碼可以快速增長，同時又保持好的內部結構，添加新的功能不是問題。

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

5. 保持品質
結對編程、對代碼復審、單元測試。對不正確、不合適的變更都要拒絕。開發者需要對設計負責。

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

7. 單元測試 打造設計
單元測試在很大程度上定性了代碼設計，它迫使我們實現好的結構，保證可測性。

8. 遵守設計
新的成員可以比較容易地拿起代碼開始工作。開發團隊動態地遵守架構設計，項目原則規定沒有人"擁有"某部分設計，而是所有人都應該寫出高品質的代碼，可以改動系統的所有地方。

未來：

1. 沒什么是一成不變的，在整潔的背景下，突出的技術爭論應該被解決掉。著重于適應性強的架構和靈活的代碼結構。

我自己遇到過的

好的系統架構：

我看過一個導航引擎的架構，這個一個好的架構，是因為：

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

2. 代碼結構清晰，功能模塊劃分后，對于底層和組件的關系進一步分析，將結構進行分層設計。劃分出common，data access等公共部分。如此，代碼的文件結構也比較清晰，每個模塊的文件夾下，有各自的頭文件與實現文件。

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

4. 統一的框架和一些代碼生成工具。保證了內部統一的風格，編碼慣例。但是這些框架和工具也增加了入門的難度。

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

6. perforce，版本控制工具。


其他：
1. 基本沒有重復的代碼
2. 獨立的模塊，單元測試，迫使結構走向高內聚，低耦合的狀態。


另外一個，說不上是失敗的系統，但是有一些特點是明顯需要改進的地方：
1. 對新成員，沒有完整的系統結構文檔可以理解

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

3. 重復的代碼隨意可見，為了及時完成業務邏輯，相同的代碼被復制粘貼。造成比較嚴重的技術債務。

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

總結

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

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