保持軟體設計的品質。壞的架構設計會招致更壞的架構設計。
開發團隊中健康的工作關係將直接有益於軟體設計。不健康的關係和個性膨脹會導致不健康的軟體。
軟體設計的關鍵品質是內聚和耦合。-- 高內聚(strongcohesion)和低耦合(low coupling)
鬆弛而模糊的架構將導致每個**元件編寫得不好，並且相互之間匹配得不好。它也會導致重複的**和工作。
不良架構的影響不僅限於**。它會進一步影響到人、團隊、過程和時間表。
重要的是要在開始設計系統之前知道你打算設計什麼。如果你不知道它是什麼，也不知道它將做什麼，暫時不要開始設計它。只設計你知道需要的東西。
扁平化團隊結構
設計第一步：
確定主要的功能領域
頂層檔案結構
如何對事物命名
「內部」展示的風格
共用的編碼慣例
選擇單元測試框架
支援基礎設施（例如版本控制、適合的構建系統和持續整合）
按照xp過程推進，設計和編碼要麼以結對的方式完成，要麼經過仔細的複審，確保工作的正確性。
架構有助於定位功能：新增功能、修改功能或修復缺陷。它為你提供了乙個模板，讓你將工作納入到一張系統導航圖中。
清晰的架構設計將導致一致的系統。所有決定都應該在架構設計的背景下做出。
清晰的架構有助於減少功能重複。軟體架構不是一成不變的。需要時就改變它。要想做到可以修改，架構就必須保持簡單。犧牲簡單性的修改要抵制。
xp原則-- yagni(如果你不是馬上需要，就不需要去做)
。延遲設計決定，知道你必須做出這些決定為止。不要在你還不知道需求的時候就做出架構決定。不要猜測。
必須保持架構品質。只有當開發者們相信它並對它負責時，才能做到這一點。
你的系統應該有一組不錯的自動化測試，它們讓你在進行根本的架構變更時風險最小。這為你提供了工作空間。
對你的**進行單元測試將帶來更好的軟體設計，所以設計時要考慮可測試性。
好的專案計畫將帶來優質的設計。分配足夠的時間來建立架構傑作，它們不會立即出現。
團隊的組織方式必然對它產生的**有影響。隨著時間的推移，架構也會影響到團隊協作的好壞。當團隊瓦解時，**的互動就很糟糕。當團隊協作時，架構就整合得很好。
Dissecting MFC 閱讀筆記 一
閱讀下面一段程式，並寫出它的執行結果 include include 成員訪問許可權和繼承控制都是 private 再加加上 整合的方式是 public 所以才能訪問資料成員 class classa void func2 virtual void vfunc1 virtual void vfunc...
Effect Java 閱讀筆記（一）
乙個靜態工廠的小例子 以下方法得到的物件是事先構造好的不可變物件，反覆利用 public static boolean valueof boolean b 使用靜態工廠的優勢 靜態工廠方法的缺點 簡而言之，如果類的構造器或者靜態工廠中具有多個引數，設計這種類時，builder模式就是不錯的選擇 si...
c primer plus閱讀筆記（一）
int a 1 undigned int b 0 cout 4294967295 typename value c typename value c static cast value 更加嚴格的強轉auto a 100 int auto b 10.0 double auto iter vector...