第五章:彎曲，或折斷
1.解耦與得墨忒耳法則
函式的得墨忒耳法則試圖使任何給定程式中的模組之間的耦合減至最少，它設法阻止了你為了獲得第三個物件的方法的訪問而進入某個物件，寫**的時候要使模組間的耦合減至最低，避免了牽一髮而動全身的可能性。我們應該跟多的考慮如何怎樣進行設計，使系統中的事物保持邏輯上的解耦。使用該法則可以我們的**適應性更好。可以使用委託來使服從墨忒耳法則更容易。
2.元程式設計
讓我們的系統變得高度可配置。要配置，不要整合。
元資料使關於資料的資料，是對應用進行描述的資料。
要用元資料描述應用的配置選項：調諧引數，使用者偏好，安裝目錄等。元資料不僅能用來配置簡單的偏好，也要盡可能多的通過元資料配置和驅動應用。
將抽象放進**，細節放進元資料。這句沒有很理解。
這種方法有若干好處:1）它迫使你解除你的設計的耦合,從而帶來更靈活、可適應性更好的程式。
2）它迫使你通過推遲細節處理,建立更健壯更抽象的設計一完全推遲到程式之外。
3）無需重新編譯應用,你就可以對其進行定製你還可以利用這一層面的定製,輕鬆地繞開正在執行的產品系統中的重大bug。
4）與通用的程式語言的情況相比,可以通過一種大為接近問題領域的方式表示元資料。
5）你甚至還可以用相同的應用引擎—一但是用不同的元資料——實現若干不同的專案。
要提高程式的適應性，否則會被淘汰的。
3.時間耦合
時間有兩個方面對我們非常重要：併發和次序。我們需要容許併發，並考慮解除任何時間或次序上的依賴。
分析工作流，以改善併發性。可以通過uml活**，或者通過構建架構，使系統中的每乙個實體都是乙個獨立實體，與其他元件一起併發執行。對時間解耦的優勢使它更易於編寫。
對併發進行設計，對靜態或全域性變數加以保護，設計更簡潔的介面。
靈活地處理應用的部署方式。
未完待續........(*╹▽╹*)
程式設計師修煉之道 從小工到專家
在專案開始之前 需求需要挖掘，而不僅僅是收集。找出使用者為何要做特定事情的原因，而不是他們目前做這件事情的方式。建立需求文件 把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯，以及可評價 通過統計資訊 需求的收集和設計實現不是單向的線性關係，而是雙向關係。它們是 交付...
程式設計師修煉之道 從小工到專家
基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設，要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...
程式設計師修煉之道 從小工到專家
這本書的適用範圍可以從初學者到有經驗的程式設計師再到專案經理，作為一本偏向理論與思想的書，書中不可避免有些假大空的地方，再加上作者寫完本書的時間還在1999年，書中的很多方法與標準放在今天也已不再實用。但這些都不能掩蓋它的優秀之處，作者曾在本書完成十年後說過，如果這本書是放在現在編寫，1999年的那...