您當前位置：首頁 > php開源 > php教程 > 《代碼整潔之道》讀書筆記

《代碼整潔之道》讀書筆記

來源：程序員人生發布時間：2015-04-18 11:45:24 閱讀次數：4676次

??最初我喜歡這本書多是由于非技術方面的緣由，這本書中有很多我喜歡的插圖。這本書的第1章的第1句話是這樣說的：讀這本書通常有兩個緣由：1. 你是1名程序員。2. 你想成為更好的程序員。我們需要更好的程序員。
??這本書的每章都可以總結出1句話，其實每章開始的插圖就是這句話的濃縮。
這里寫圖片描述
??本書的第1章是關于甚么是整潔代碼的討論，援用了Bjarne Stroustrup（C++之父）、Grady Booch（UML的開創人之1）等人固然也Bob大叔（本書的作者Robert Martin）自己對整潔代碼的理解。順便說1下，上面那張圖上的代碼應當是保齡球計分程序（不知道大家看清楚了沒有，哈哈）。

這里寫圖片描述
??不論是現實世界還是軟件項目中，命名都是1件讓人頭疼的事情，給小孩起過名字的就知道，你希望把你對孩子的期望包括在這個名字中，你又希望這個名字讀起來要好聽，最少不至于將來成為他人的笑柄（比如龐光大、魏升京這樣的名字），可能你還要斟酌族譜班輩的排列等等。軟件項目中的命名情況會更加復雜，簡單的說命名的原則是"見名知意"，固然你還需要用各種方式防范命名沖突的問題，不同的編程語言也有自己不成文的像契約1樣的命名規則和方式（例如匈牙利命名法），這些可能都是需要斟酌的事情。我個人其實不喜歡匈牙利命名法，加上1個類型前綴的感覺就是永久和這個東西綁定到1起了，就猶如用C語言的malloc函數分配內存創建1個能放100000個元素的數組，你愿意用下面哪一種寫法呢？記住：好的名字相當于為代碼寫了1段有用的注釋。

    int* myArray = NULL;
    /* 寫法1 */
    myArray = malloc(100000 * sizeof(int));
    /* 寫法2 */
    myArray = malloc(100000 * sizeof *myArray);

這里寫圖片描述
??第3章講的是函數，說了這么1句話："Function should do one thing. They should do it well. They should do it only. "（函數只應當做1件事情，把1件事情做好，而且只由它來做這1件事情），聽起來很簡單的1句話但是要踐行這條原則卻其實不容易，所以我們的代碼中才會有很多的壞味道（請參考《重構：改良既有代碼的設計》1書的第3章）。事實上，上升1個層次，我們在設計類的時候也應當如此，這是面向對象設計原則中說的單1職責原則（SRP），當我們的代碼中出現了冗雜的方法或巨大的類的時候，我們就應當根據職責來對其進行拆分，這樣程序的結構才會趨于公道，終究到達"高內聚"的目標。固然，這1章里面還提到很多理念，包括：Command Query Separation（1個方法要末履行某種命令，要末返回查詢數據）、DRY（不要重復自己）、Prefer Exceptions to Returning Error Codes（異常優于返回毛病碼）等。

這里寫圖片描述
??第4章講的是注釋，有1句話我很喜歡，說的是："Comments Do Not Make Up for Bad Code."（注釋不是對劣質代碼的補救）。事實上好的代碼即使沒有注釋也具有良好的可讀性，但恰當的注釋會讓代碼變得更可讀、可保護性更高。

這里寫圖片描述
??第5章講的是代碼風格。現代IDE（集成開發環境）幾近都有代碼格式化代碼的功能，你只需要設置好你使用的代碼風格就能夠了，其實不只是IDE，很多高級的文本編輯工具也能夠依照指定的風格格式化你的代碼。用甚么樣的代碼風格不是關鍵，關鍵是全部項目組的成員應當使用相同的代碼風格，讓多個人編寫的代碼看起來像1個人書寫的。我個在代碼中使用的括號風格是1TBS（One True Bracing Style，也叫做K&R風格，這類風格是Kernighan和Ritchie兩位老師在"The C Programming Language"1書中使用的代碼風格），固然Allman風格（FreeBSD系統的作者之1使用的代碼風格）也是很好的選擇。

這里寫圖片描述
??第6章討論的是對象和數據結構，讀完以后的感覺是雖然我們每天都嚷著吼著要面向對象編程，但是很多時候我們都使用了類的退化結構，包括我們開發時常常使用的失血模型和貧血模型（事務腳本模式）都和面向對象的設計理念相背背。我得承認在讀這1章的時候我可能沒有捉住作者的觀點。

這里寫圖片描述
??第7章對毛病處理（異常）的講授非常精彩的，整潔的代碼中對毛病的處理應當是被分離的關注點（不要跟正常的業務邏輯混雜在1起），而面向對象中的異常機制就是1種在不打亂原有業務邏輯的條件下處理掉程序在運行時產生的不正常狀態的手段。這章有兩個觀點我特別欣賞，1是"Use Unchecked Exceptions"（非受檢異常允許你在適當的地方處理異常，而適當的地方就是異常影響代碼履行邏輯的地方，不管做哪一種類型的利用，都應當盡量向用戶隱藏異常的產生，除非產生了不可挽救的狀態，這才是符合最小驚訝原則的設計）；2是"Don’t Return Null"（如果1個方法在出狀態的時候返回null，那末調用者都要通過頻繁的檢查返回值來判定是不是出錯，1旦忘了這件事情就有可能出錯，既然null是1種異常狀態，那末用拋出異常的方式來代替返回null明顯是更好的做法）。

這里寫圖片描述
??第8章的內容對實際開發有重要的指點意義，由于我們的項目中不可避免的要使用第3方工具，因此我們需要將這些東西整潔的納入到我們的系統中，這時候就需要斟酌系統邊界的問題。有的時候我們會千辛萬苦的發現系統中的1些bug是來源于第3方工具的，固然我們基本上沒有時間去重頭學習和研究第3方工具或自己寫代碼來實現第3方工具的功能，但是我們最少應當先對第3方工具進行測試。我在之前的項目中，即便用Apache提供的那些著名的第3方工具，我的做法也是先寫測試代碼對這些工具的可用性和有效性進行證實，固然有的時候多是過于謹慎了，但這類習慣和做法本身是很好的。在這類場景下，適配器模式是非常好的設計，它不但能將不兼容的接口改寫成兼容的接口，還能夠對通過對第3方工具重新封裝來避免邊界的變化對系統的影響。

這里寫圖片描述
??第9章的內容是單元測試。Bob大叔是TDD（測試驅動開發）的提倡者，這1章講的是如何編寫整潔的測試，Bob大叔的答案是FIRST規則（Fast、Independent、Repeatable、Self-Validating、Timely）。

這里寫圖片描述
??第10章介紹類的設計，最重要的還是SRP（單1職責原則）。

這里寫圖片描述
??第101章是關于系統設計的內容，開篇援用了微軟首席技術官Ray Ozzie的1句話："Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test."（復雜要人命，它消磨開發者的生命，讓產品難于計劃、構建和測試）。這章對希望了解面向切面編程的開發者是極好的，包括了對依賴注入、代理模式和AOP的探討。