概述

花了幾天時間看完了程序員修煉之道，有很多感悟，記錄於此，供自己開發時參考，相信對其他人也有用。

值得一提的是，這本書寫的非常好，很多大牛在走了很多彎路之後再讀這本書都很感慨沒有早些讀。

《程序員修煉之道》讀書筆記①

彎曲，或折斷

• 解耦與得墨忒耳法則

1.函數的得墨忒耳法則規定，某個對象的任何方法都應該只調用屬於以下情形的方法：它自身；傳入該方法的任何參數；它創建的任何對象；任何直接持有的組件對象。

2.委托服從得墨忒耳法則，從而減少了耦合。

• 元程序設計

1.元數據是關於數據的數據；要用元數據描述應用的配置選項。

2.有些配置是只在程序啟動時掃描的，因此如果這些配置發生了改動，那麽程序就需要重啟來更新這些數據。

• 時間耦合

1.事務處理系統就是一個時間解耦的系統，也就是安排事物並發運行的系統。

2.我們可以用事件把某個對象的狀態變化通知給可能感興趣的其他對象。這樣使用事件使得那些對象之間的耦合得以減至最少——事件發送者不需要對接收者有任何明確的了解。

3.為什麽要使用樹視圖。因為樹視圖與解耦有很深的關系。

• 黑板

1.這是我唯一存在疑惑的地方，黑板系統在編程中到底是個什麽樣的系統。

當你編碼時

• 靠巧合編程

1.只要你在制作代碼，你就應該記住，有一天你必須對其進行測試，要讓代碼易於測試，這樣你將增加它實際通過測試的可能性。

• 算法速率

1.某個O(n^2)算法可能比另一個O(n^2)算法要快1000倍，但你從表示法上卻看不出來。

2.對於較小的n值，簡單的O(n^2)循環的性能可能會比復雜的O(nlg(n))算法更好，特別是當O(nlg(n))算法有昂貴的內循環時。

3.如果你不確定代碼需要多少時間，或是要使用多少內存，就試著運行它，變化輸入記錄的數目，或可能影響運行時間的無論什麽東西。隨後把結果繪制成圖。

• 重構
• 易於測試的代碼

1.我們喜歡把單元測試視為針對合約的測試。

2.測試時的熱鍵雖然不會透露給最終用戶，但這對於客戶服務人員卻非常方便。

• 邪惡的向導

1.我們雖然在使用向導，但是我們也要理解它制作出的所有代碼。

在項目開始之前

• 需求之坑

1.在討論用戶界面時，需求，政策和實現之間的區別可能會變得非常模糊：“系統必須能讓你選擇期限”是對需求的陳述；“我們需要一個列表框，以選擇期限”可能是，也可能不是。如果用戶一定要有列表框，那麽他是需求。相反，如果他們是在描述選擇能力，但只是用列表框做例子，這個陳述就可能不是需求。

2.你的開發必須解決他們的商業問題，而不只是滿足他們陳述的需求。

3.成功的工具會適應使用它們的雙手。

• 解開不可能解開的謎題

1.當你認為你的問題是“不可能解決的”時候，問自己這些問題：有更容易的方法嗎？你是在設法解決真正的問題，還是被外圍的技術問題轉移了註意力？這件事情為什麽是一個問題？是什麽使它如此難以解決？它必須以這種方式完成嗎？它真的必須完成嗎？

• 等你準備好

1.作為開發者，你在整個職業生涯中都在做同樣的事情。你一直在試驗各種東西，看哪些可行，哪些不可行。

• 規範陷阱
• 圓圈與箭頭

1.計算技術從來都不缺少意圖使程序設計更像工程的方法。

2.形式開發方法只是工具箱裏的又一種工具，不要成為方法學的奴隸。

3.註重實效的程序員批判地看待方法學，並從各種方法學中提取精華，融合成每個月都在變得更好的一套工作習慣。

註重實效的項目

• 註重實效的團隊

1.確保每個人都主動地監視環境的變化。可以指定一個“首席水情監測員”。

2.傑出的項目團隊有著截然不同的個性，人們希望與他們一同開會，因為他們知道自己將看到準備良好，會讓每個人都感到愉悅的演出。

3.有一個簡單的營銷訣竅，能幫助團隊作為整體與外界交流：創立品牌。

4.按照對你的授權，你越接近用戶，級別就越高。

5.項目至少需要2個“頭”：一個主管技術，另一個主管行政。

6.找一找成功的團隊，他們成功的原因是什麽？

• 無處不在的自動化

1.你可以決定創建一個shell腳本來完成一些煩人的工作，但你仍然要記得在需要時運行這個腳本。

• 無情的測試

1.使用自動測試的團隊成功的機會要大得多。

2.代碼在它通過所有可用的測試之前，你不能聲稱它已經可供使用。

3.一旦你有了可執行的用戶界面或原型，你需要回答一個最重要的問題：用戶告訴了你他們需要什麽？但那是他們需要的嗎？

4.性能測試，壓力測試或負載測試也可能會是項目的一個重要方面。

5.回歸測試把當前測試的輸出與先前的值進行對比。

6.你編寫了一個測試，你還要故意引發bug，並確定測試會發出提示。

7.覆蓋分析工具會在測試過程中監視你的代碼，追蹤哪些代碼執行過?哪些沒有？

• 全部是寫

1.寫註釋或文檔——把英語當做又一種編程語言。

2.比無意義的名稱更糟糕的是誤導人的名稱。

3.在源文件裏應該出現的最重要的信息之一是作者的姓名。

4.現在大多數完善的字處理器都有宏語言，嘗試用下宏語言。

5.現在許多技術作者使用DocBook來定義他們的文檔。DocBook是一種基於SGML的標記語言。

6.項目的成功是由它在多大程度上滿足了用戶的期望來衡量的。

• 極大地期望

1.管理期望：主動控制用戶對他們能從系統中得到什麽應該抱有的期望。

2.隨著項目的進展，聽取你的用戶的意見，了解什麽特性會使他們真的高興。

• 傲慢與偏見

1.我們想要看到對所有權的自豪。“這是我編寫的，我對自己的工作負責”。你的簽名應該被視為質量的保證。

《程序員修煉之道》讀書筆記②