功能擴充套件：
1. 新**的定位
一開始就有系統結構清晰的總體檢視，所以，新的功能單元可以新增到正確的功能區域，而不是為了一時方便，**隨意新增。（這樣，有的時候開發者的工作會需要動寫腦筋，但是在系統維護和擴充套件時，就變得容易了）
2. 系統的一致性
頂層設計的良好風格和決定，為底層**好處，**是統
一、整潔的。清晰的定義，確保沒有重複的**、介面慣例和常見設計模式被普遍使用、沒有特殊生命週期的物件和資源管理問題。（這個重點是在於減少功能重複）
3. 架構增長
沒有什麼是一層不變的，架構應該是方便擴充套件、可重構的。這樣，**可以快速增長，同時又保持好的內部結構，新增新的功能不是問題。
4. 延遲設計決定
這部分應該是需求問題。yagni（如果不是馬上需要，就不要去做），早期只設計中要的部分，將餘下的決定推遲。特別是，不確定的需求，需要猜測。
5. 保持品質
結對程式設計、對**複審、單元測試。對不正確、不合適的變更都要拒絕。開發者需要對設計負責。
6. 技術債務管理
什麼是技術債務？為了趕時間，對於不太重要的功能被砍掉，允許小的**"瑕疵"存在，發布時避免高風險的改動。這些都應該被標記為技術債務。
應該選擇合適的時間，及時集中清理這些技術債務，在後續版本中修改。
7. 單元測試 打造設計
單元測試在很大程度上定性了**設計，它迫使我們實現好的結構，保證可測性。
8. 遵守設計
新的成員可以比較容易地拿起**開始工作。開發團隊動態地遵守架構設計，專案原則規定沒有人"擁有"某部分設計，而是所有人都應該寫出高品質的**，可以改動系統的所有地方。
架構之美02
1.新 的定位 一開始就有系統結構清晰的總體檢視，所以，新的功能單元可以新增到正確的功能區域，而不是為了一時方便，隨意新增。這樣，有的時候開發者的工作會需要動寫腦筋，但是在系統維護和擴充套件時，就變得容易了 2.系統的一致性 頂層設計的良好風格和決定，為底層 好處，是統 一 整潔的。清晰的定義，確保...
架構之美 二 （摘要）
第二章 兩個系統的故事 2.1 混亂大都市 總結出的特徵 1.需要花極長的時間學習，沒有顯而易見的進入系統的路徑。2.從每個程式，每個方法，每個元件來看，都是混亂而粗糙的疊在一起。不存在一致性，不存在風格，也沒有統一的概念能夠將不同的部分組織在一起。3.系統中的控制流讓人覺得很不舒服，無法 4.資料...
架構之美隨筆五 語言與架構
美 作為軟體架構的口號，並不是由旁觀者來判定的。其實早就存在一些明確的標準。可靠性 該架構能否幫助我們建立出正確 健壯的軟體。可擴充套件性 應對變化是否很容易。復用性 該解決方案是否具有同樣性，或者甚至可以將其作為乙個元件直接插入到新的應用程式中，而無需做定製開發。這部分內容，作者從之前所概括的軟體...