架構之美第2章兩個系統的故事現代軟體神話

這一章節，作者拿他曾經參與過的兩個專案對比好架構與壞架構的表現和影響，經驗之談

壞設計的一些表現：

1，不可理解：重要的是要保持軟體設計的品質。壞的架構設計會招致更壞的架構設計

2，缺乏內聚：開發團隊中健康的工作關係將直接有益於軟體設計。不健康的關係和個性膨脹會導致不健康的軟體。內聚性是將模組粘成乙個整體的膠水。弱內聚的模組是不良分解的訊號。每個模組都必須具有清晰定義的角色，而不只是一堆不相關的功能。

3，不必要的耦合：緊耦合將導致不可測試的**

4，**重複問題：鬆弛而模糊的架構將導致每個**元件編寫得不好，而且相互之間匹配得不好。它也會導致重複的**和工作。

5，**以外的問題：不良架構的影響不僅限於**。它會進一步影響到人，團隊，過程和時間表

好設計的一些表現：

1，在開始設計系統之前知道你打算設計什麼。如果你不知道它是什麼，也不知道它將做什麼，暫時不要開始設計它。只設計你知道需要的東西。

2，較早的確定主要的功能領域，推出初步的架構，包括了實現效能需求所必需的核心執行緒模型。在系統核心上花了額外的設計時間。

3，早期確定了一些基本關注點，目的是確保**能夠容易而一致地增長，包括：a，頂層檔案結構；b，如何對事物命名；c，內部展示的風格；d，共用的編碼慣例；e，選擇單元測試框架；f，支援基礎設施（例如版本控制，適合的構建系統和持續整合）

4，定位功能：架構有助於定位功能：新增功能、修改功能或修復缺陷

5，一致性：清晰的架構設計將導致一致的系統。所有決定都應該在架構設計的背景下做出。清晰的架構有助於減少功能重複

6，架構的增長：開發團隊的一項核心原則就是保持敏捷，沒有什麼是一成不變的，所以在需要時架構也可以修改。要做到可以修改，架構就必須保持簡單。犧牲簡單性的修改要抵制。

7，延遲設計決定，直到我們對實際的需求有了更清晰的理解並知道如何放到系統中最好時，再做出這些決定

8，保持品質：開發者們相信設計，認為設計對專案相當重要。他們擁有設計，對設計負責

9，管理技術債務。隨著專案期限的臨近，一些不太重要的功能被砍掉，並標記為技術債務，安排在後續版本中

10，單元測試打造了設計：單元測試的好處之一是能夠修改軟體的一些部分，而不必擔心在修改的過程中破壞其他的東西。另外可在很大程度上定型了**設計，編寫單元測試確保了每個**模組的內聚性，也確保了與系統其他部分之間的松耦合。設計時要考慮可測試性。

11，有利的專案環境，合適的設計時間

架構之美 第2章 兩個系統的故事 現代軟體神話