最初我喜歡這本書可能是因為非技術方面的原因，這本書中有很多我喜歡的插圖。這本書的第一章的第一句話是這樣說的：讀這本書通常有兩個原因：1. 你是一名程序員。2. 你想成為更好的程序員。我們需要更好的程序員。這本書的每一章都可以總結出一句話，其實每章開始的插圖就是這句話的濃縮。
??本書的第一章是關于什么是整潔代碼的討論，引用了Bjarne Stroustrup（C++之父）、Grady Booch（UML的創(chuàng)始人之一）等人當然也包括Bob大叔（本書的作者Robert Martin）自己對整潔代碼的理解。順便說一下，上面那張圖上的代碼應該是保齡球計分程序（不知道大家看清楚了沒有，哈哈）。
??不管是現實世界還是軟件項目中，命名都是一件讓人頭疼的事情，給小孩起過名字的就知道，你希望把你對孩子的期望包含在這個名字中，你又希望這個名字讀起來要好聽，至少不至于將來成為別人的笑柄（比如龐光大、魏升京這樣的名字），可能你還要考慮族譜班輩的排列等等。軟件項目中的命名情況會更加復雜，簡單的說命名的原則是"見名知意"，當然你還需要用各種方式防范命名沖突的問題，不同的編程語言也有自己不成文的像契約一樣的命名規(guī)則和方式（例如匈牙利命名法），這些可能都是需要考慮的事情。我個人并不喜歡匈牙利命名法，加上一個類型前綴的感覺就是永遠和這個東西綁定到一起了，就如同用C語言的malloc函數分配內存創(chuàng)建一個能放100000個元素的數組，你愿意用下面哪種寫法呢？記住：好的名字相當于為代碼寫了一段有用的注釋。
int* myArray = NULL;
/* 寫法1 */
myArray = malloc(100000 * sizeof(int));
/* 寫法2 */
myArray = malloc(100000 * sizeof *myArray);
??第三章講的是函數，說了這么一句話："Function should do one thing. They should do it well. They should do it only. "（函數只應該做一件事情，把一件事情做好，而且只由它來做這一件事情），聽起來很簡單的一句話但是要踐行這條原則卻并不容易，所以我們的代碼中才會有很多的壞味道（請參考《重構：改善既有代碼的設計》一書的第三章）。事實上，上升一個層次，我們在設計類的時候也應該如此，這是面向對象設計原則中說的單一職責原則（SRP），當我們的代碼中出現了冗長的方法或者巨大的類的時候，我們就應該依據職責來對其進行拆分，這樣程序的結構才會趨于合理，最終達到"高內聚"的目標。當然，這一章里面還提到很多理念，包括：Command Query Separation（一個方法要么執(zhí)行某種命令，要么返回查詢數據）、DRY（不要重復自己）、Prefer Exceptions to Returning Error Codes（異常優(yōu)于返回錯誤碼）等。
??第四章講的是注釋，有一句話我很喜歡，說的是："Comments Do Not Make Up for Bad Code."（注釋不是對劣質代碼的補救）。事實上好的代碼即便沒有注釋也擁有良好的可讀性，但恰當的注釋會讓代碼變得更可讀、可維護性更高。
??第五章講的是代碼風格。現代IDE（集成開發(fā)環(huán)境）幾乎都有代碼格式化代碼的功能，你只需要設置好你使用的代碼風格就可以了，其實不只是IDE，很多高級的文本編輯工具也能夠按照指定的風格格式化你的代碼。用什么樣的代碼風格不是關鍵，關鍵是整個項目組的成員應當使用相同的代碼風格，讓多個人編寫的代碼看起來像一個人書寫的。我個在代碼中使用的括號風格是1TBS（One True Bracing Style，也叫做K&R風格，這種風格是Kernighan和Ritchie兩位老師在"The C Programming Language"一書中使用的代碼風格），當然Allman風格（FreeBSD系統(tǒng)的作者之一使用的代碼風格）也是很好的選擇。
??第六章討論的是對象和數據結構，讀完之后的感覺是雖然我們天天都嚷著吼著要面向對象編程，但是很多時候我們都使用了類的退化結構，包括我們開發(fā)時經常使用的失血模型和貧血模型（事務腳本模式）都和面向對象的設計理念相違背。?作者在本章闡述的一些觀點我個人是不太接受的，對軟件和代碼的理解也可以仁者見仁智者見智。
??第七章對錯誤處理（異常）的講解非常精彩的，整潔的代碼中對錯誤的處理應當是被分離的關注點（不要跟正常的業(yè)務邏輯混雜在一起），而面向對象中的異常機制就是一種在不打亂原有業(yè)務邏輯的前提下處理掉程序在運行時發(fā)生的不正常狀況的手段。這章有兩個觀點我特別欣賞，一是"Use Unchecked Exceptions"（非受檢異常允許你在適當的地方處理異常，而適當的地方就是異常影響代碼執(zhí)行邏輯的地方，不管做哪種類型的應用，都應該盡可能向用戶隱藏異常的發(fā)生，除非發(fā)生了不可挽救的狀況，這才是符合最小驚訝原則的設計）；二是"Don't Return Null"（如果一個方法在出狀況的時候返回null，那么調用者都要通過頻繁的檢查返回值來判定是否出錯，一旦忘了這件事情就有可能出錯，既然null是一種異常狀況，那么用拋出異常的方式來代替返回null明顯是更好的做法）。
??第八章的內容對實際開發(fā)有重要的指導意義，因為我們的項目中不可避免的要使用第三方工具，因此我們需要將這些東西整潔的納入到我們的系統(tǒng)中，這時就需要考慮系統(tǒng)邊界的問題。有的時候我們會千辛萬苦的發(fā)現系統(tǒng)中的一些bug是來源于第三方工具的，當然我們基本上沒有時間去重頭學習和研究第三方工具或者自己寫代碼來實現第三方工具的功能，但是我們至少應該先對第三方工具進行測試。我在以前的項目中，即使用Apache提供的那些著名的第三方工具，我的做法也是先寫測試代碼對這些工具的可用性和有效性進行證實，當然有的時候可能是過于謹慎了，但這種習慣和做法本身是很好的。在這種場景下，適配器模式是非常好的設計，它不僅能將不兼容的接口改寫成兼容的接口，還能夠對通過對第三方工具重新封裝來避免邊界的變化對系統(tǒng)的影響。
??第九章的內容是單元測試。Bob大叔是TDD（測試驅動開發(fā)）的倡導者，這一章講的是如何編寫整潔的測試，Bob大叔的答案是FIRST規(guī)則（Fast、Independent、Repeatable、Self-Validating、Timely）。
??第十章介紹類的設計，最重要的還是SRP（單一職責原則）。
??第十一章是關于系統(tǒng)設計的內容，開篇引用了微軟首席技術官Ray Ozzie的一句話："Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test."（復雜要人命，它消磨開發(fā)者的生命，讓產品難于規(guī)劃、構建和測試）。這章對于希望了解面向切面編程的開發(fā)者是極好的，包括了對依賴注入、代理模式以及AOP的探討。
??第十二章探討了系統(tǒng)的迭代式演進。
??第十三章對并發(fā)編程的討論非常經常，很多開發(fā)者都畏懼并發(fā)編程，也有的開發(fā)者迷信多線程可以解決所有的并發(fā)問題，如果你是這兩類人之一，本章會教給你真正的并發(fā)編程。這一章的內容我重新整理了一篇文章，已經發(fā)布在CSDN的博客上，名為《關于Java并發(fā)編程的總結和思考》。
??第十四章是一個精彩的案例用來講解對代碼的持續(xù)改進，你可以自己好好閱讀一次。第十五章到第十七章說的都是重構，相當精彩。如果你還沒有來得及讀《重構：改善既有代碼的設計》一書，你可以先讀讀這幾張中探討的代碼的壞味道及其改進方案。
總之，這本書從引言到附錄都無比精彩，書中的代碼是用Java語言書寫的，如果你是Java程序員就更不要錯過了。
