《程序員修煉之道》摘錄

1.個人源碼讓貓給吃了——不要找藉口，要負責。

2.軟件的熵——不要容忍「破窗戶」（低劣的設計、錯誤決策或是糟糕的代碼），見一個修個。

3.石頭湯與煮青蛙——作變化的催化劑，避免「啓動雜役」；記住打圖景，溫水煮青蛙。

4.足夠好的軟件——使質量稱爲需求問題；避免過分修飾。

5.你的知識資產——按期爲你的知識資產投資（最簡單的就是買書）；批判地分析你讀到的和聽到的。

6.交流——被打量比被忽略要好（這個深有體會）；你說什麼和你怎麼說一樣重要。

7.重複的危害——DRY

8.正交性——消除無關事物之間的影響。

9.可撤銷性——若是某個想法是你惟一的想法，在沒有什麼比這更危險的事情了；不存在最終決策；靈活的架構。

10.曳光彈——原型製做生成用過就扔的代碼。曳光彈代碼雖然簡約，但倒是完整的，而且構成了最終系統的骨架的一部分。

11.原型與便箋——任何帶有風險的事物。之前沒有試過的事物或是對於最終系統終端極端關鍵的事物。原型並不必定要編寫代碼，有時用便箋就能夠。

12.領域語言。

13.估算——多準確才足夠準確

　　時長                                       報出估算的單位

   1-15天                                              天

    3-8周                                               周

    8-30周                                             月

    30+周                                     在給出估算前努力思考一下

14.純文本的威力。

15.shell 遊戲——利用命令shell的力量。

16.強力編輯器——（vim 或 sublime text）。

17.源碼控制——（git或svn）。

18.調試——最容易欺騙的人是一我的本身；不要恐慌；調試的思惟方式。

19.文本操縱——學習一種文本操縱語言。

20.代碼生成器——編寫能生成代碼的代碼（《黑客與畫家》中也提到這一點）。

21.按合約設計。

22.死程序不說謊——早崩潰；檢查每個可能的錯誤。

23.斷言式編程——若是它不可能發生，用斷言確保它不會發生。

24.什麼時候使用異常——將異經常使用於異常的問題。

25.怎樣配平資源——要善始善終。

26.解耦與得墨蕊耳法則——模塊之間的耦合減至最少。

函數的得墨忒耳法則規定，某個對象的任何方法都應該只調用屬於如下情形的方法：
class Demeter
{
public:
   void example(B &b);
private:
    A *a;
    int func(){}
}
void Demeter::example(B &b)
{
    C c;
    int f = func(); <------------------1. 它自身
    b.invert(); <----------------------2. 傳入該方法的任何參數
    a = new A();
    a->setActive(); <------------------3. 它建立的任何對象
    c.print(); <-----------------------4. 任何直接持有的組件對象
}
得墨忒耳法則縮小了調用類中的響應集的規模，結果以這種方式設計的類的錯誤也每每更少。

27.元程序設計——要配置，不要集成；將抽象放進代碼，細節放進元數據。（有所體會）

28.時間耦合——分析工做流，以改善併發性；架構、併發、接口、部署。

29.它只是視圖——發佈/訂閱；MVC。

30.黑板——用黑板協調工做流。

31.靠巧合編程——編寫本身能控制的代碼，不要靠巧合編程。

32.算法速率。

33.重構——早重構，常重構。

34.易於測試的代碼——單元測試；構建測試窗口。

35.邪惡的嚮導——不要使用你不理解的嚮導代碼。

36.需求之坑——不要蒐集需求，要挖掘他們；用戶；文檔。

37.解開不可能解開的謎題——何時堅持，何時改變。

38.等你準備好——何時準備，何時開始。（要有良好的判斷）

39.規範陷阱——對有些事情「作」勝於「描述」。

40.圓圈與箭頭——不要作形式的奴隸。

前面這七章是對我的而言，第八章對團隊而言（後面再看）

關鍵詞：重構  單元測試 沒有解不開的難題  交流 曳光彈  元程序設計 DRY 正交性 對代碼負責 」等你準備好「