第二章：兩個系統的故事
2.1 混亂大都市
總結出的特徵
1. **需要花極長的時間學習，沒有顯而易見的進入系統的路徑。
2. 從每個程式，每個方法，每個元件來看，**都是混亂而粗糙的疊在一起。不存在一致性，不存在風格，也沒有統一的概念能夠將不同的部分組織在一起。
3. 系統中的控制流讓人覺得很不舒服，無法**
4. 資料很少放在使用它的地方，經常引入額外的巴羅克式快取層，目的是試圖讓資料停留在更方便的地方。（注：巴羅克一詞原指不規則的，怪異的珍珠）
5. 不好的公司結構和不健康的開發過程將在糟糕的軟體架構中得到體現。
6.糟糕架構的後果：
a)不可理解：注意，重要的是保持軟體設計的品質。壞的架構設計會招致更壞的架構設計（壞的設計確實會招致在他上面疊加壞的設計）
b)缺乏內聚：系統元件完全沒有內聚。每個元件本來應該有乙個定義好的角色，但他們卻包含了一堆雜亂的，不一定相關的功能，這使我們很難確定元件存在的原因，也很難弄明白系統中已實現了哪些具體功能。功能和資料放在系統中錯誤的地方，「核心服務」沒有在系統核心部分實現。
c)不必要的耦合：模組之間的依賴關係不是單向的，耦合常常是雙向的。元件a會到達元件b的內部完成一項任務。其他地方，元件b又通過硬編碼呼叫了元件a。單個元件的任何改變都會波及其他元件。**層次的測試不能進行，元件層次的整合測試也不能建立。
d)**問題：沒有命名規範；重複：通用演算法和資料結構在**集中不斷重複出現，很多實現都帶有一些未知的缺陷和怪異的行為特徵；更大範圍的關注點，如外部通訊和資料快取也實現了很多次。
e)**以外的問題：架構的腐爛影響到了支援和使用它的人：
i. 開發團隊：專案複雜性導致流失率提高；專案壓力大；規劃新功能導致極大的恐懼。
ii. 緩慢的開發周期：難以維護，管理軟體開發周期非常困難，管理層對開發團隊不能滿足業務目標失望
iii. 支援工程師：需要了解很小的軟體版本差異之間錯綜複雜的行為差異
iv. 第三方支援：外部支援協議也反映出此架構，第三方工程師難以理解
v. 公司內部政治：開發與營銷團隊關係緊張。
7. 清晰的需求：混亂的重要原因是：專案開始之初，團隊不知道要構建什麼。開始設計架構之前，需要知道你打算設計什麼。只設計你知道需要的東西。
8. 缺少預見性和架構設計，將導致一下問題；
a) 低品質的**和漫長的軟體版本發布週期。
b) 系統沒有彈性，不能適應變更或新增新的功能。
c) 無處不在的**問題。
d) 員工問題（壓力大，士氣低，跳槽等）
e) 大量混亂的公司內部政治。
f) 公司不能成功。
g) 許多痛苦和面對**深夜加班。
2.2 設計之城
1. 第一步，確定主要的功能領域。
2. 系統中各獨立部分的相對位置關係體現為傳統的分層結構。
3. 早期選擇了專案將採用的支援庫。
4. 決定一些基本關注點，使**能夠容易且一致的增長，包括：
a) 頂層檔案結構
b) 如何對事物命名
c) 「內部」展示風格
d) 共用的的編碼慣例
e) 選擇單元測試框架
f) 支援基礎設施（如版本控制，適合的構建系統和持續整合）
5. 按照xp（極限程式設計）過程推進，設計和編碼要麼以結對的方式完成，要麼經過仔細的複審。
6. 良好架構產生的結果：
a)定位功能：一開始就有系統清晰總體檢視，新的單元可一致性的加到**集的正確功能區域。新**放到「正確位置」比簡單放到方便的位置可能要更難，但回報是：維護或擴充套件系統時，不愉快的事情會減少。架構有助於定位功能：新增功能，修改功能或修復缺陷，他為你提供乙個模板，讓你將工作納入到一張系統導航圖中
b)一致性：清晰的架構導致一致的系統。所有的決定都應該在架構設計的背景下做出。清晰的架構有助於減少功能重複.
c)架構的增長:系統設計像**一樣,被認為是可擴充套件,可重構的。軟體架構並非一成不變，要想做到可以修改，架構必須保持簡單，犧牲簡單性的修改要抵制。
d)延遲設計決定：延遲設計決定，知道必須做出決定為止。不要在還不知道需求時就坐出架構決定。不要猜測。xp（極限程式設計）的一項原則：yagni:如果你不是馬上需要，就不要去做。早期只設計重要的部分，剩餘決定推遲。直到對實際需求有了更清晰的理解，並知道如何放在系統中最好時，再做出決定。
i. 當你還不理解問題是就開始設計，是一件糟糕的事。
ii. 建立軟體設計時加入所有可能需要的東西是危險的：大部分設計將是無用功，得到的只是額外負擔，需要在整個生命週期支援這些設計。，一開始就增加成本。
e)保持品質：準備一些品質控制過程：1.結對程式設計，2.對沒有結對程式設計的工作進行**/設計複審。3.對每一段**進行單元測試。必須保持架構品質，開發者相信它並對他負責時，才能做到。
f)管理技術債務：注重開發時效，最後期限臨近，不太重要功能砍掉，使產品準時推出。小的**「瑕疵」或設計問題允許存在於**集中：為了讓功能盡快實現或在接近發布時避免高風險改動。這些問題被標記為技術債務，安排在後續版本修復。
g)單元測試打造了設計:
i.所有**都要單元測試，（xp極限程式設計開發強制要求的）。單元測試帶了很多好處，其中一項就是：能夠修改軟體的一些部分，而不必擔心在修改的過程中破壞其他的東西。系統應該有一組不錯的自動化測試，使得在進行架構變更時風險最小。
ii. 單元測試的另乙個好處：很大程度上定型了系統設計：迫使我們實現更好的設計。編寫單元測試確保了每個模組的內聚性，也確保系統其他部分之間的松耦合。對你的**進行單元測試將帶來更好的軟體設計，所以設計時要考慮可測試性。
h)i)與設計同行：團隊的組織方式必然對他產生的**有影響，隨著時間推移，架構也會影響團隊協作的好壞。conway法則：**結構符合團隊結構：如果讓四個小組開發乙個編譯器，會得到乙個四階段編譯器。
7. 好的架構是很多因素的結果：
a) 確實進行有意為之的前端設計
b) 設計者的素質和經驗
c) 在開發過程中，保持清晰的設計觀點
d) 授權團隊負責軟體的整體設計，而團隊也承擔起這一責任
e) 不要害怕改變設計，沒有什麼是一成不變的
f) 讓合適的人加入到團隊中，包括設計者，程式設計師，經理，確保開發團隊的規模合適。確保它們之間健康的工作關係。
g) 在合適的時候做出決定，當知道所有必要資訊時再做出決定。延遲暫時不能做出的決定。
h) 好的專案管理，適合的最後期限
《架構之美》閱讀筆記二
架構是系統設計的一部分，它突出了某些細節，並通過抽象省略掉了另一些細節。軟體系統的架構包括行為上的和結構上的。外部行為描述展示了軟體如何與使用者 其他裝置和外部裝置進行互動，也就是需求。結構描述展示了軟體如何被劃分為多個部分，以及這些部分的關係。在大多數人的談論中，架構是乙個目標產物，而作為架構師的...
架構之美閱讀筆記二
第二部分企業級架構包含四章，這次總結這一部分的前三章。分別主要講了多人遊戲架構技術 影響系統架構的兩個方面 功能和約束 建立資料驅動的應用的資源對映的作用。第四章記憶存留，採用開發系統來將電子轉化成墨水原子和紙張的例子來引出這一章要講的架構。功能和約束是影響系統架構的兩方面關鍵因素。在研究架構的每乙...
架構之美2
功能擴充套件 1.新 的定位 一開始就有系統結構清晰的總體檢視，所以，新的功能單元可以新增到正確的功能區域，而不是為了一時方便，隨意新增。這樣，有的時候開發者的工作會需要動寫腦筋，但是在系統維護和擴充套件時，就變得容易了 2.系統的一致性 頂層設計的良好風格和決定，為底層 好處，是統 一 整潔的。清...