對鮑勃大叔《Clean Code》書籍各種不同意見的評論收集

這是各種讀者對羅伯特·C·馬丁（Robert C. Martin）2008年的著作《清潔程式碼》評論，點選標題見英文：

我寫這篇文章是因為我一直看到人們推薦Clean Code。我覺得有必要提出反對意見。最初我是在公司組織的閱讀小組中閱讀“清潔程式碼”的。我們每週閱讀一章，共十三週。（這本書有十七章，由於已經提到的原因，我們跳過了一些章節。）

我會推薦這本書嗎？不。我是否建議將它作為初學者使用？否。

Clean Code的主要問題是書中的許多示例程式碼簡直令人恐懼。“清潔法規”將強大而永恆的建議與非常可疑或過時的建議兩者混淆在一起了。

這本書的大部分內容不再有用，基本上有幾章就是為填充而填充，有整整一章介紹了JUnit的內部結構。這本書來自2008年。關於程式碼格式化有一整章內容，如今已簡化為一句話：“選擇明智的標準程式碼格式化，配置自動工具以實施它“，然後再也不要考慮這個主題。

其餘內容幾乎完全專注於物件導向的程式碼，並讚揚SOLID的優點，以排除其他程式設計範例。物件導向的程式設計在釋出之時非常流行，但是那時是缺少函式性程式設計技術。

近年來，擁護SOLID觀點的人數也一直在穩步下降。該書著重於Java程式碼，排除了其他程式語言，甚至其他物件導向的程式語言。Java當時很流行，Java可能是正確的選擇，但是如今有更好的選擇。最後，本書對Java的整體使用非常過時。即使對於2008年，本書所提供的許多java程式碼也不是很好的。

該書向我們展示了TDD迴圈：

第一定律除非單元測試失敗，否則您不得編寫生產程式碼。

第二定律您編寫的單元測試可能不會超過失敗的總數，並且編譯不會失敗。

第三定律您編寫的生產程式碼數量可能不足以通過當前失敗的測試。

這三個定律將您鎖定在一個可能長達三十秒的迴圈中。測試和生產程式碼是一起編寫的，而測試僅比生產程式碼提前幾秒鐘。

但是這本書並沒有承認這個過程中缺少的第零步：弄清楚如何分解擺在您面前的程式設計任務。

鮑勃大叔寫道：

這兩個示例說明了物件和資料結構之間的區別。物件將其資料隱藏在抽象之後，並公開對該資料進行操作的函式。資料結構公開其資料，並且沒有有意義的功能。返回並再次閱讀。注意這兩個定義的互補性質。他們是對立的。這種差異看似微不足道，但卻具有深遠的意義。

鮑勃大叔對“資料結構”的定義與其他人所使用的定義不同！儘管Martin確實明確定義了他的用語，但這是一種非常奇怪的定義。(banq注：認為鮑勃大爺這樣的定義很奇怪？是不是自己也很奇怪？反正奇怪人的看別人覺得奇怪。很多人之前接受的OO認知是空白，他們主要從資料角度理解一切，而不是從行為職責去看問題，所以，這種顛覆對於他們是措不及防的，被懷疑成很奇怪的的定義)

最近，我看到了許多反對Clean Code的強烈反對。作為軟體新手，這對我來說是具有變革性的，向我介紹了可測試性和可讀性之類的概念，而這些概念在大學中他們並未告訴我們。它給了我一個討論程式設計的詞彙。它簡短易懂，沒有一些繁瑣的例子。因此，直到有人提出了一種無懈可擊的替代方案之前，我將繼續向新手推薦它，但要告誡他們應該保留一些個人意見，並跳過無聊的部分。只要您有更多經驗豐富的開發人員向您展示實際上良好的程式設計，就不會對你造成太大的傷害。

John Ousterhaut的軟體設計哲學。這是一本簡短易讀的書，深入探討了有關軟體開發的真相。我讀過關於如何編寫軟體的最好的一本書。

兩本書絕對是垃圾書：分別是Code Complete和The Clean Architecture書。我完全不會推薦他們。

John Ousterhout的“軟體設計哲學”是一個很好的選擇。簡潔，精巧的書，其中包含許多實現細節，這些細節經過透徹思考並智慧呈現。

《簡潔程式碼》是一本非常有用的書，它將對99％的初級開發人員有所幫助。您想證明它的某些部分（或程式碼示例）不那麼好，那就去做，但是如果您希望100％同意400頁的材料來將一本書歸類為“好”或“有用”，那您就被誤導了。我們是開發人員，而不是蹣跚學步的小動物，請閱讀並使用批判性思維來決定要保留什麼和丟棄什麼。

我認為乾淨程式碼的想法很荒謬。程式碼應該簡單明瞭。一個普遍的陷阱是過度設計，使程式碼變得比需要複雜。但是我在程式設計的各個方面都看到了這一點，人們花了數小時來建立構建檔案（Cmake等），建立UML圖，預定義API，還建立了不必要的函式和類（“以後可能需要”） ）等。坦白地說，這只是浪費時間。（banq注：過度設計有時是擴充套件自己理解新業務領域的廉價方式，對未知業務領域通過各種零成本的折騰踩坑是為了避免使用大量瑣碎程式碼踩坑，程式碼是最昂貴，當然除非你願意無限制加班，用程式碼替代思考）

讓我對Martin的方法感到絕對瘋狂的是他幾乎出於宗教的堅持，即在編寫程式碼之前不要“選擇資料庫”。關係代數是20世紀最重要的演算法之一，但是Martin希望您使用自己編寫的程式碼來編寫和管理自己的關係。對我來說，已經擁有完善的強執行機制時卻自己編寫管理關係的程式碼，這是程式流程的錯誤。我發現令人惱火的另一件事是，我還會遇到那些堅持“沒有框架”的人。鮑勃大叔說您的程式碼不應該與Javabeans或Django有關，而應該與它的含義有關：如果您要編寫工資核算應用程式，則該應用程式的儲存庫應顯示“工資核對！”。這是很好的建議。但是，每次檢視以“乾淨程式碼”標準編寫的應用程式時，我都會看到標有“領域”，“服務”，“ use_cases”，“閘道器”，“介面卡”的資料夾。我稱其為“編寫乾淨程式碼框架”，因為這就是事實。

我從觀看SICP講座視訊時記得的一件事是，您應該將程式碼視為定義一種新語言，並使用函式（語言中最有用的術語）來分解程式碼。我認為這是非常基本的建議，但與馬丁在本書中所討論的內容：如果將程式碼分解為最少但必需的函式，則可以通過有意義的概念/動作的結構和顯式命名來使程式碼更清晰。馬丁似乎已經相當大地扭曲了SICP想法。他的零註釋程式碼理念：您不必將註釋寫在每行的旁邊，而是將其放入一個與該註釋相同的函式中，這是一種自我記錄程式碼的奇怪方法。（零註釋程式碼：程式碼即是註釋，無需過多自然語言）

 感謝您對馬丁的觀點的強烈反駁。我看過太多的人拿著這本書作為有關如何編寫程式碼的最新參考。對我來說，我所見到的主要問題是他對零註釋程式碼的痴迷。我覺得這很瘋狂，因為它導致您描述了無數怪異的命名方法，最終使程式碼變得絕對不可讀。但是好處是它使人們意識到編寫程式碼的方式很重要。

這對我來說是一本具有革命性意義的書，讀起來很難。

鮑勃大叔說資料庫是事後才考慮的且不重要的。在那之後，我失去了對他的尊重。(banq注：這是一位可愛的資料庫宗教虔誠者)

在過去幾年裡閱讀了近一百本有關程式設計的書籍之後，我仍然建議“ Clean Code”作為我的最愛。作為一個新的開發人員，我在學校沒有學過保持方法簡單和名稱易讀。這本書對這兩件事的強調是值得的。

我認為OO和FP思維之間存在衝突。關於FP的所有內容都與OO概念相反：1）關注資料及其轉換（而不是物件之間的訊息）。2）不要變異（變化狀態，物件只是函式的袋子）。3）傳遞您需要的所有內容（如上面的評論者所述，這違反了物件屬性的全部目的）。我認為這兩個陣營是不相容的，儘管一些物件導向的想法似乎傾向於FP的想法。OO損壞了我的大腦，FP似乎正在恢復它:)

FP和OOP是完全相容。這大約是我們在工作時所採用的方式：FP適用於所有小規模事務：資料是純資料，並由純方法操縱。不變的資料結構，返回而不是引用，重新建立而不是修改。這裡沒有OOP。然後，應用程式程式碼將責任區分開；有些地方是可以保留狀態並通過業務級方法對其進行改變狀態的類：每組資料僅在一個類中儲存和變化。可以改變的任何狀態資料都是私有的，不會對外分發任何對其的可變引用。 大多數情況下，OOP僅用於分離程式碼庫不同區域之間的介面和實現，並使用依賴性注入以避免依賴性迴圈。程式碼重用主要通過組合而不是繼承來實現。