在雙十一與朋友拼單，考慮了好久決定買這一本書《代碼整潔之道》。相信大多數接觸編程的同行多多少少都聽過這本書吧。此次用了五天晚上閑暇時間完成了前面十三章的閱讀。該文談不上總結，所以我在擬定題目的時候還是挺糾結的。希望與這本書有緣的您討論。
下面我把自己看完前面部分的總結寫下
第一章：整潔代碼
這章先是給我們傳遞一個觀點：整潔代碼是十分有必要的。然后就列舉了幾位java大師級人物對整潔代碼的定義和看法。
真正有用的就是這些大師人物的觀點，都是經過幾十年的編程經驗總結而成的，下面我再將這些觀點進行總結，得到以下幾個“真理”。
1、盡量減少依賴關系，便于維護
2、簡單直接，充滿了干凈利落的抽象和直截了當的控制語句。
3、能夠全部運行通過，并配有單元測試和驗收測試
4、沒有重復的代碼（提取公共方法和公共類）
5、寫的代碼能夠完全提現我們的設計理念（類、方法、屬性的命名）
第二章：有意義的命名
取個好名字在于需要良好的描述技巧和文化背景。文化背景是沒辦法了，不過本章節提到了一些可以考慮的技巧提高參考。想著以前命名的時候也是十分的痛苦，必須得好好加強了，到了一定的時候得多看一些英語書籍了。驚喜是：點擊下載該書英文版。
1、所有的命名都要有實際意義
2、語義中不要添加java常用類（list），避免引起誤導
3、程序中有意義的數字應該用常量進行替換，方便查找
4、類名和對象名應為名詞或名詞詞組，方法名應為動詞或動詞詞組。
5、屬性命名添加有用必要的語境，如果類名本身自帶語境，就不必添加多余語境
問題：每個概念對應一個詞
第三章：函數
函數是代碼的主體部分，也是我們最需要注意的地方。很欣賞里面一句話：大師級的程序員把系統當做故事來講，而不是當程序來寫
1、短?。?0封頂最佳
2、if,else,while語句塊應該只有一行（調用其他邏輯函數）函數的縮進層級不該對于一層或兩層
3、每個函數一個抽象等級
4、switch語句通常用多臺進行實現
5、函數參數盡量少，絕對不要多于2個，多于2個就要進行封裝。
6、分隔指令和詢問。經常在讀流中的數據這樣寫到if(null!=(s=br.readLine())),以后要分開寫
7、抽取異常處理，即try-catch就是一個函數
第四章：注釋
以前上學的時候老師經?；貜娬{注釋的重要性，到現在還傻傻地認為寫注釋就是一個好喜歡，完全沒有考慮到問什么要用注釋，什么時候該用注釋，怎樣寫出好的注釋。
1、盡量在名字中體現，而不需要添加額外的注釋
2、警示作用以及放大某些函數的重要性
本章節后面來列舉了一大堆的壞注釋，感覺注釋還是少用，所以我們要注重在命名中加以體現
第五章：格式
本章節主要是對平常寫代碼格式具體說明，我覺得算是本書中講的最具體的一章了，很容易理解，但看完之后我們應該要總結出屬于自己的模板，當然鮑勃大叔在章節末尾處給出了他的一些規范，我們可以在此基礎上進行修改成我們自己的格式。下面羅列本章觀點。
1、垂直方向的區別、靠近和距離
2、若某個函數調用了另外一個，就應該把它們放在一起，而且調用者要放在被調用者上面。
3、水平方向的區隔與靠近（包括每行最多字符數），區隔我學到具體的兩個是方法參數和運算符之間的間隔。
4、注意縮進，這里提到一個具體的就是if,else等代碼塊只有一行甚至是為空的時候，我們也要進行縮進，不能偷懶
第六章：對象和數據結構
得墨忒耳律：模塊不應該了解它所操作對象的內部情形。準備的說類C的方法f只能調用以下對象的方法：C、由f創建的對象、作為參數傳遞給f的對象、由c的實體變量持有的對象
火車失事：不能采用連綴的寫法，以前在寫有關IO的代碼總是連著寫，現在得一行行寫。
數據結構：數據結構是數據的載體，暴露數據，而幾乎沒有意義的行為，像我們最常見到的DTO，以及與采用JDBC連接數據庫時的實體類，都是一種數據結構的提現，只存在簡單的get和set方法。
對象：對象作為面向對象的產物，必須封裝隱藏數據，而暴露出行為接口。DDD中領域模型傾向于對象不僅在數據更多暴露行為操作自己或者關聯狀態。
重點：? 使用數據結構的代碼便于在不改動現在數據結構的前提下添加新的行為（函數），面向對象代碼則便于不改動現 有函數的前提下添加新的類。換句話說就是數據結構難以添加新的的數據類型，因為需要改動所有函數，面向對象的代碼則難以添加新的函數，因為需要修改所有的類。在任何一個復雜的系統都會同時存在數據結構和對象，我們需要判斷的是我們需要的是需要添加的新的數據類型還是新的行為函數。
第七章：異常處理
因為平時對異常沒有什么總結，也很少自己去自己寫異常處理，所以這章節的觀點都不是很清晰。對我有用的就是：別返回null或者是試圖傳遞null
第八章：瀏覽和學習邊界
問題：建議不要講Map（或在邊界上的其他接口）在系統中傳遞。如果你使用Map這樣的邊界接口，就把它保留在類或近親類中。避免從公共API中返回邊界接口，或將編輯接口作為參數返回公共API。
學習性測試：不要在生產代碼中試驗新東西，而是編寫測試來遍歷和理解第三方代碼。
整潔的邊界：如果我們只是需要某個第三方插件的一部分API時，可以采用適配器模式進行轉化。
第九章：單元測試
本章節提到了關于TDD(測試驅動開發)的相關知識，關于這方面的知識網上一大堆，我就把本書的觀點抽取出來。
TDD三定律
You are not allowed to write any production code unless it is to make a failing unit test pass.
除非為了使一個失敗的unit test通過，否則不允許編寫任何產品代碼
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
在一個單元測試中只允許編寫剛好能夠導致失敗的內容（編譯錯誤也算失?。?/p>
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
只允許編寫剛好能夠使一個失敗的unit test通過的產品代碼
關于測試：測試代碼和生產代碼一樣重要，我們也要保持整潔，另外單元
測試可以使我們的代碼可擴展、可維護、可復用。每個測試只有一個斷言。
第十章：類
1、類應該短小
2、單一權責原則：每個類或模塊只有一條加以修改的理由
3、內聚：內聚的程度是類中的方法和變量相互依賴的程度
4、依賴倒轉原則：面向接口編程
第十一章：系統
1、將系統的構建與使用分開
2、Java中的代理（Spring AOP的實現原理）
第十二章：遞進
闡述了簡單設計的四條規則，按重要性一次排序
1、運行所有測試：
2、不可重復：利用手段將程序進行代碼層面上的重構
3、表達程序員的意圖：這個主要體現在命名和結構上
4、盡可能減少類和方法數量
個人感覺做到好難，多次反復看前面章節有的在現在編程中還是可以立馬見成效的。但是有的我現在的水平還是無法完完全全理解，所以只能先珍藏該書，也算是裝了一回逼。不過建議你不要停留在我上面的總結而是真真實實去看書，收獲屬于你自己的體會，深刻明白代碼整潔的重要性并加于實施。歡迎留言探討
