書的示例是Java語言編寫的，雖說不會影響閱讀，但是后面幾章講應用這套方法論的時候，大篇幅的Java代碼分析還是挺難受的，而且連java測試框架Junit都要細講，對于非Java系的開發者來說，一些內容確是云里霧里。
書的前2/3能夠適用全部的開發者，讀完有很大收獲。后面1/3講到依賴注入，AOP等內容，這已經是Java的高級理論了，沒有基礎的讀者理解起來還是比較費勁的。還有就是自動化測試是為開發者提供了很好的重構基礎，不過這個實踐還是需要在大公司才有機會嘗試。
以下總結了一些自己閱讀時的一些要點，雖然還未來得及切身實踐，拜讀之時卻也頗有感受，這種書還是要反復閱讀，實踐之后會有更多體會。

代碼整潔之道

• 程序員遵從不了解混亂風險的經理的意愿，也是不專業的做法
• 整潔的代碼只做好一件事
• NameString會比Name好嗎？難道Name會是一個浮點數不成？
• 明確是王道
• 類名不應當是動詞
• 給每個類添加“GSD”前綴就不是什么好點子，為什么要搞得IDE沒法幫助你？
• 函數的第一規則是要短小，第二條規則是還要更短小
• 函數應該做一件事，做好這件事，只做這一件事
• 對于switch語句，我的規矩是如果只出現一次，用于創建多態對象，而且隱藏在某個繼承關系中，在系統其他部分看不到，就還可能忍受
• 標識參數丑陋不堪，宣布本函數不止做一件事，true or false
• 當一組參數被共同傳遞，就像point的x、y那樣，往往可以從參數創建對象，從而減少參數數量
• 最好把try/catch代碼塊的主體部分不分抽離出來，另外形成函數
• 我并不從一開始就按照規則寫函數，我想沒人做得到
• 別給糟糕的代碼加注釋——重新寫吧
• 直接把代碼注釋掉是討厭的做法，別這么干
• 你今天編寫的功能，極有可能在下一版本中被修改，但代碼的可讀性卻會對以后可能發生的修改行為產生深遠影響
• 類并不簡單地用get和set將其變量推向外間，而是暴露抽象接口，以便用戶無需了解數據的實現就能操作數據本體
• 過程是代碼便于在不改動既有數據結構的前提下添加新函數，面向對象代碼便于在不改動既有函數的前提下添加新類。
• 對象暴露行為，隱藏數據；數據結構暴露數據，沒有明顯的行為
• 當錯誤發生時，程序員有責任確保代碼照常工作
• 如果無法為某個類命以精確的名稱，這個類大概就太長了
• 系統應該由許多短小的類而不是少量巨大的類組成
• 通常而言，方法操作的變量越多，就越粘聚到類上（內聚UP）
• 軟件項目的主要成本在于長期維護
• 對象是過程的抽象，線程是調度的抽象

總結

以上是生活随笔為你收集整理的[读书笔记] 代码整洁之道的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。