好代碼，壞代碼

22年年中看完《代碼整潔之道》之後，常關注着相關信息，前段時間看到一本名叫《好代碼·壞代碼》的書，我感覺這名字起的很是“響亮”，於是將其讀了一遍。這本書我看的紙質版，每個晚上看40分鐘，讀完歷時一個月，全書讀完花費約15小時。 本書分爲三個部分：理論、實踐與測試。 理論闡述軟件工程師在編寫代碼時是如何考慮與權衡的：怎樣的代碼算是好的代碼，好代碼應該擁有怎樣的結構，與其他工程師交流時該用怎樣的代碼契約，以及在錯誤發生時怎樣通知才能更快地定位問題。 實踐則是在講理論知識可以怎樣真正運用到代碼中去。只每章的標題就很能說明問題： 編寫易於理解的代碼； 避免意外； 編寫難以被誤用的代碼； 實現代碼模塊化； 編寫可重用、可推廣的代碼。 這是理論中所提到6個代碼質量支柱的前5個，也是書中篇幅最長，講解最詳細的部分。 代碼質量的最末1個支柱是“編寫可測試的代碼並適量測試”，這也是本書的第三部分——單元測試，這部分分爲理論和實踐兩個章節。 本書絕大部分內容，都是成對出現的。 標題中“好代碼”對“壞代碼”；具體章節內容先講壞代碼的“長相”、壞代碼可能會造成的影響，待講過“壞處”之後，作者再提出可能的優化方向，展示好代碼該有的樣子。 本書的組織方式，給我一種“提出問題，然後解決問題”的清晰感受。 開始閱讀本書時，是剛完成一個小（爲確認“小”的規模，我藉助VS Code Counter統計了一下代碼行數，一共12k）項目後端框架搭建不久，正在往搭起來的架子中添磚加瓦。 到整理本篇讀書筆記時，這小項目的主體功能已基本完成。所以，整個閱讀過程，亦是我的開發過程，這理論與實踐的互相印證，使得以下4點，是我認識最深刻的。 一、代碼契約 代碼契約在書中的定義是： 工程師將不同代碼段之間的交互視爲一種契約：調用者必須履行一些義務，作爲回報，調用的代碼將返回預期的值或修改某些狀態。不應該有任何不清晰或意外的情況。因爲一切都該在契約中定義。這是最完美的情況，現實世界是並不完美的。契約有明確無疑的部分，也會存在並不明確的附屬細則。好代碼，應該儘量將不明確的點減少到最低，不過分依賴附屬細則。 細化到項目中，以函數舉例，一個函數的功能，應該由它本身的輸入輸出準確界定，而並非由相關文檔、註釋來輔助說明。文檔是可能過期的，真正“說話算數”的，只是代碼。我們寫一個函數，要儘量保證它不需要額外的依賴項。 一切都該是準確的。 二、錯誤處理 我還在網易做遊戲的時候，項目組內有一個口口相傳，傳了至少十幾年的規則：服務端的報錯要直接報出來，客戶端的報錯可以做兼容處理，但也該把堆棧打到log中去。 待讀到本書“顯式報錯、隱式報錯”時，真正感受到理論是來源於實踐的，作者肯定寫過許多代碼，他的整理與大佬們的經驗一致。 書中示例“尋找松露的狗”是很形象的比喻：我們藉助狗的嗅覺找松露，好狗會在找到松露時立馬停下並叫出聲來，壞狗找到松露隨意向周圍走10步後再叫；明顯好狗找松露的效率更高。 當代碼中有錯誤出現時，是該立馬讓這錯誤報出來的。這能更準確定位問題，由此，能更快地解決問題。（經過本書的再次提醒，我將代碼中好幾處返回空值做兼容處理的地方，改成了斷言。） 三、分層和模塊 書中說“如果我們能將一個問題拆分爲很多的小問題，並創建抽象層次，任何一段單獨的代碼看起來都不會很複雜，因爲一次只需要理解幾個概念。” 我是從這理念中受益匪淺的。軟件開發中，分層與模塊處處存在，大到網絡協議的分層，中到引擎與邏輯的拆分，再小到我這項目，都使用了分層結構。其它的不提，以我的小項目舉例，它的分層結構來源於Django 的REST framework框架： URL層列出接口列表； View層定義接口，處理接口權限和訪問頻次； Serializer層處理具體的邏輯； Models層只關注數據表的形式。 每個層當中，又拆分爲（儘量）各不相關的小模塊。藉助REST framework設計系統，我在定位問題、迭代需求時，速度是很快的。 四、可讀性與防禦性設計 小時候切菜，老媽經常告訴我：“切完菜，菜刀全身不要伸出竈臺，以免誤碰到地上，掉落過程很危險；刀口要朝裏，再拿的時候不給機會劃到手。”這是生活中的防禦性習慣。 代碼如是。 代碼應該是防禦性設計的，要避免編寫擁有誤導性的函數，要減少調用者出現誤用的可能性。模塊、類、函數的命名，參數、變量的作用域，都該是含義準確的。 讀完本書，我很是認同作者所傳達出的觀點——我們每個人都是會犯錯誤的；作爲程序員，我們寫的代碼是肯定會出bug的。我們能做的，是認真對待自己的代碼，多花心思在代碼上面；是藉助前人的經驗，使用良好的代碼風格，避免犯前人犯過的重複錯誤；最終減少bug的產量。 作者在介紹許多寫代碼原則之外，也說到“切忌生搬硬套規則，現實世界需求多變，我們是可以根據需求做些變化的。” 作者說本書適合有0~3年軟件工程師工作經驗的人閱讀。我想將這年限再擴大些：1~10年經驗的程序員們都可以讀上一讀。這兩個數字由我自己的經驗得來，如果剛畢業的我看本書，極可能看不下去；我現在敲代碼快滿10年，讀完依然能有許多感悟，我認爲是很值得看的。 本書的推薦語爲：“看過《代碼整潔之道》之後，不妨再看看《好代碼·壞代碼》。這兩本書相輔相成，它們都專注於提升我們的編程技能，使我們寫出更易懂的代碼。”

在一本技術書裏，怎麼會有一份食譜啊！好離譜

值得花時間通讀的一本書，裏面講到的原則大多數老程序員都不清楚，只有在腦中有好代碼的標準，纔有可能寫出好代碼。

挺好的一本書，休息時，沒事看看，收穫還挺多👀

最初工作時，只想着把功能完成就好了。寫代碼時只考慮業務邏輯，不會考慮什麼異常，擴展，複用等內容。 本書定義了什麼是好代碼，同時給出了一些技巧。有了些工作經驗的我在閱讀這些內容時，很容易聯想到實際項目代碼中的各種問題。 技巧中很多都是些實用的經驗主義，所以要結合實際項目來運用，具體問題具體分析。 以後寫代碼要根據這些內容多加思考後再動手。

老生常談，感覺像是先用 ai 寫好結構，然後再用 ai 填充，很多說了很沒說一樣的廢話，偏偏又很通順，像極了 ai。有沒有用呢？這本書如果能把最開始餵給 ai 的那篇短文章拿出來，然後給剛學編程不久的人看，確實有點用。

有過一些體驗理解，看完這本算是體系化了一些，還是要多多思考實操。理解需求，明確未來，分離變化和不變，獨立，抽象簡化思考。

日常代碼提交的peer review大多拘於形式，整個團隊的code review效果更好，但需要投入更多的時間。養成更好的習慣，寫更好的代碼，繼續研讀

good code, bad code.這本書適合cpp, java開發者。新手看了升級，老手看了頓悟。全書分三個部分:理論、實踐、單元測試。提出代碼質量的6大支柱，並分別介紹其現象、問題所在、解決方案，以及方案的優缺點。6大支柱並不孤立，是相互交織的，書中經常提到。 注:本書屬於經驗性總結內容，有的地方比較抽象。因此並不適合沒有經驗的初學者。

《好代碼壞代碼》從代碼編寫的角度簡單講述了好代碼的why、what，詳細介紹了how，比如：抽象層次、代碼契約、錯誤處理、編寫易於理解的代碼、避免意外、編寫難以被誤用的代碼、實現代碼模塊化、編寫可重用可推廣的代碼、單元測試原則和實踐。總體讀下來談不上經典，內容豐富，是一本偏經驗總結性的書，缺少一定的體系完整性，後續可供查閱使用。