最初我喜歡這本書可能是因為非技術方面的原因花椭，這本書中有很多我喜歡的插圖讯泣。這本書的第一章的第一句話是這樣說的：讀這本書通常有兩個原因：1. 你是一名程序員阵漏。2. 你想成為更好的程序員预侯。我們需要更好的程序員木羹。這本書的每一章都可以總結出一句話甲雅，其實每章開始的插圖就是這句話的濃縮。
??本書的第一章是關于什么是整潔代碼的討論坑填，引用了Bjarne Stroustrup（C++之父）抛人、Grady Booch（UML的創(chuàng)始人之一）等人當然也包括Bob大叔（本書的作者Robert Martin）自己對整潔代碼的理解。順便說一下穷遂，上面那張圖上的代碼應該是保齡球計分程序（不知道大家看清楚了沒有函匕，哈哈）。
??不管是現(xiàn)實世界還是軟件項目中蚪黑，命名都是一件讓人頭疼的事情，給小孩起過名字的就知道中剩，你希望把你對孩子的期望包含在這個名字中忌穿，你又希望這個名字讀起來要好聽，至少不至于將來成為別人的笑柄（比如龐光大结啼、魏升京這樣的名字）掠剑，可能你還要考慮族譜班輩的排列等等。軟件項目中的命名情況會更加復雜郊愧，簡單的說命名的原則是"見名知意"朴译，當然你還需要用各種方式防范命名沖突的問題井佑，不同的編程語言也有自己不成文的像契約一樣的命名規(guī)則和方式（例如匈牙利命名法），這些可能都是需要考慮的事情眠寿。我個人并不喜歡匈牙利命名法躬翁，加上一個類型前綴的感覺就是永遠和這個東西綁定到一起了，就如同用C語言的malloc函數(shù)分配內(nèi)存創(chuàng)建一個能放100000個元素的數(shù)組盯拱，你愿意用下面哪種寫法呢盒发？記住：好的名字相當于為代碼寫了一段有用的注釋狡逢。
int* myArray = NULL;
/* 寫法1 */
myArray = malloc(100000 * sizeof(int));
/* 寫法2 */
myArray = malloc(100000 * sizeof *myArray);
??第三章講的是函數(shù)宁舰，說了這么一句話："Function should do one thing. They should do it well. They should do it only. "（函數(shù)只應該做一件事情，把一件事情做好奢浑，而且只由它來做這一件事情）蛮艰，聽起來很簡單的一句話但是要踐行這條原則卻并不容易，所以我們的代碼中才會有很多的壞味道（請參考《重構：改善既有代碼的設計》一書的第三章）雀彼。事實上印荔，上升一個層次，我們在設計類的時候也應該如此详羡，這是面向?qū)ο笤O計原則中說的單一職責原則（SRP）仍律，當我們的代碼中出現(xiàn)了冗長的方法或者巨大的類的時候，我們就應該依據(jù)職責來對其進行拆分实柠，這樣程序的結構才會趨于合理水泉，最終達到"高內(nèi)聚"的目標。當然窒盐，這一章里面還提到很多理念草则，包括：Command Query Separation（一個方法要么執(zhí)行某種命令，要么返回查詢數(shù)據(jù)）蟹漓、DRY（不要重復自己）炕横、Prefer Exceptions to Returning Error Codes（異常優(yōu)于返回錯誤碼）等。
??第四章講的是注釋葡粒，有一句話我很喜歡份殿，說的是："Comments Do Not Make Up for Bad Code."（注釋不是對劣質(zhì)代碼的補救）。事實上好的代碼即便沒有注釋也擁有良好的可讀性嗽交，但恰當?shù)淖⑨寱尨a變得更可讀卿嘲、可維護性更高。
??第五章講的是代碼風格》虮冢現(xiàn)代IDE（集成開發(fā)環(huán)境）幾乎都有代碼格式化代碼的功能拾枣，你只需要設置好你使用的代碼風格就可以了，其實不只是IDE，很多高級的文本編輯工具也能夠按照指定的風格格式化你的代碼梅肤。用什么樣的代碼風格不是關鍵司蔬，關鍵是整個項目組的成員應當使用相同的代碼風格，讓多個人編寫的代碼看起來像一個人書寫的姨蝴。我個在代碼中使用的括號風格是1TBS（One True Bracing Style俊啼，也叫做K&R風格，這種風格是Kernighan和Ritchie兩位老師在"The C Programming Language"一書中使用的代碼風格）似扔，當然Allman風格（FreeBSD系統(tǒng)的作者之一使用的代碼風格）也是很好的選擇吨些。
??第六章討論的是對象和數(shù)據(jù)結構，讀完之后的感覺是雖然我們天天都嚷著吼著要面向?qū)ο缶幊坛椿裕呛芏鄷r候我們都使用了類的退化結構豪墅，包括我們開發(fā)時經(jīng)常使用的失血模型和貧血模型（事務腳本模式）都和面向?qū)ο蟮脑O計理念相違背。?作者在本章闡述的一些觀點我個人是不太接受的黔寇，對軟件和代碼的理解也可以仁者見仁智者見智偶器。
??第七章對錯誤處理（異常）的講解非常精彩的，整潔的代碼中對錯誤的處理應當是被分離的關注點（不要跟正常的業(yè)務邏輯混雜在一起）缝裤，而面向?qū)ο笾械漠惓C制就是一種在不打亂原有業(yè)務邏輯的前提下處理掉程序在運行時發(fā)生的不正常狀況的手段屏轰。這章有兩個觀點我特別欣賞，一是"Use Unchecked Exceptions"（非受檢異常允許你在適當?shù)牡胤教幚懋惓１锓桑m當?shù)牡胤骄褪钱惓Ｓ绊懘a執(zhí)行邏輯的地方霎苗，不管做哪種類型的應用，都應該盡可能向用戶隱藏異常的發(fā)生榛做，除非發(fā)生了不可挽救的狀況唁盏，這才是符合最小驚訝原則的設計）；二是"Don't Return Null"（如果一個方法在出狀況的時候返回null检眯，那么調(diào)用者都要通過頻繁的檢查返回值來判定是否出錯厘擂，一旦忘了這件事情就有可能出錯，既然null是一種異常狀況锰瘸，那么用拋出異常的方式來代替返回null明顯是更好的做法）刽严。
??第八章的內(nèi)容對實際開發(fā)有重要的指導意義，因為我們的項目中不可避免的要使用第三方工具避凝，因此我們需要將這些東西整潔的納入到我們的系統(tǒng)中舞萄，這時就需要考慮系統(tǒng)邊界的問題。有的時候我們會千辛萬苦的發(fā)現(xiàn)系統(tǒng)中的一些bug是來源于第三方工具的恕曲，當然我們基本上沒有時間去重頭學習和研究第三方工具或者自己寫代碼來實現(xiàn)第三方工具的功能鹏氧，但是我們至少應該先對第三方工具進行測試。我在以前的項目中佩谣，即使用Apache提供的那些著名的第三方工具，我的做法也是先寫測試代碼對這些工具的可用性和有效性進行證實实蓬，當然有的時候可能是過于謹慎了茸俭，但這種習慣和做法本身是很好的吊履。在這種場景下，適配器模式是非常好的設計调鬓，它不僅能將不兼容的接口改寫成兼容的接口艇炎，還能夠?qū)νㄟ^對第三方工具重新封裝來避免邊界的變化對系統(tǒng)的影響。
??第九章的內(nèi)容是單元測試腾窝。Bob大叔是TDD（測試驅(qū)動開發(fā)）的倡導者缀踪，這一章講的是如何編寫整潔的測試，Bob大叔的答案是FIRST規(guī)則（Fast虹脯、Independent驴娃、Repeatable、Self-Validating循集、Timely）唇敞。
??第十章介紹類的設計，最重要的還是SRP（單一職責原則）咒彤。
??第十一章是關于系統(tǒng)設計的內(nèi)容疆柔，開篇引用了微軟首席技術官Ray Ozzie的一句話："Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test."（復雜要人命，它消磨開發(fā)者的生命镶柱，讓產(chǎn)品難于規(guī)劃旷档、構建和測試）。這章對于希望了解面向切面編程的開發(fā)者是極好的歇拆，包括了對依賴注入鞋屈、代理模式以及AOP的探討。
??第十二章探討了系統(tǒng)的迭代式演進查吊。
??第十三章對并發(fā)編程的討論非常經(jīng)常谐区，很多開發(fā)者都畏懼并發(fā)編程，也有的開發(fā)者迷信多線程可以解決所有的并發(fā)問題逻卖，如果你是這兩類人之一宋列，本章會教給你真正的并發(fā)編程。這一章的內(nèi)容我重新整理了一篇文章评也，已經(jīng)發(fā)布在CSDN的博客上炼杖，名為《關于Java并發(fā)編程的總結和思考》。
??第十四章是一個精彩的案例用來講解對代碼的持續(xù)改進盗迟，你可以自己好好閱讀一次坤邪。第十五章到第十七章說的都是重構，相當精彩罚缕。如果你還沒有來得及讀《重構：改善既有代碼的設計》一書艇纺，你可以先讀讀這幾張中探討的代碼的壞味道及其改進方案。
總之，這本書從引言到附錄都無比精彩黔衡，書中的代碼是用Java語言書寫的蚓聘，如果你是Java程序員就更不要錯過了。
