有個代碼庫里的"發(fā)送郵件"功能，套了七層抽象殼子。郵件服務(wù)調(diào)用郵件供應(yīng)商，供應(yīng)商包裝郵件客戶端，客戶端呼叫郵件適配器，適配器使用消息發(fā)送器，發(fā)送器觸發(fā)傳輸層——層層剝完，才真正碰到郵件API。

每層都有正當(dāng)理由：這里記日志，那里做容錯，中間塞重試邏輯。按行業(yè)共識的標(biāo)準(zhǔn)，這幾乎就是"整潔代碼"的范本。問題是，團(tuán)隊里已經(jīng)沒人能完整搞懂這套東西了。

這就是沒人敢說的真相——當(dāng)有人在代碼評審里跟你引用Bob大叔時。

Robert Martin的書出版于2008年，給了開發(fā)者一套詞匯和規(guī)則：函數(shù)要短、命名要有意義、單一職責(zé)、不寫注釋因為代碼應(yīng)該自解釋。好想法，確實是。但接下來發(fā)生的事才是問題。

開發(fā)者把一套特定場景下的實用建議，變成了放之四海皆準(zhǔn)的通用標(biāo)準(zhǔn)。整潔代碼從工具變成了身份標(biāo)簽。寫整潔代碼說明你是正經(jīng)開發(fā)者，寫別的就是偷懶、走捷徑、不敬業(yè)。一旦某件事變成身份認(rèn)同，它就不再被質(zhì)疑。

于是開發(fā)者開始給不需要抽象的東西加抽象。給永遠(yuǎn)不會有第二個實現(xiàn)的類創(chuàng)建接口。把函數(shù)拆成子函數(shù)再拆成子子函數(shù)，直到原始邏輯分散在十二個文件里，想搞清楚代碼到底在干什么得花四十分鐘考古。

全都是為了"整潔"。沒一件是為了真正解決問題。

2023年，程序員Casey Muratori發(fā)了條視頻叫《整潔代碼，糟糕性能》。他把Bob大叔的整潔代碼示例拿出來，跟直來直去的實現(xiàn)做基準(zhǔn)測試。整潔版本慢了最多23倍。

整潔代碼社區(qū)的反應(yīng)可想而知：性能對大多數(shù)應(yīng)用不重要，瓶頸通常在數(shù)據(jù)庫，你這是過早優(yōu)化。有些話確實在理——現(xiàn)代軟件大部分時間都在等用戶輸入，不是在執(zhí)行業(yè)務(wù)邏輯。對很多應(yīng)用來說，性能差距確實無關(guān)痛癢。

但這不是Muratori的核心論點。他的重點是：整潔代碼規(guī)則被包裝成放之四海皆準(zhǔn)、脫離上下文的定律，但它們不是。它們是權(quán)衡。每加一層抽象，就多一層要理解的東西。每個小函數(shù)都是讀者大腦里的上下文切換。每個接口都是一層掩蓋實際發(fā)生什么的間接層。

整潔代碼只是把復(fù)雜度挪了地方，并沒有消除它。

誠實代碼不是亂寫代碼，不是想怎么寫就怎么寫還美其名曰風(fēng)格選擇。誠實代碼是承認(rèn)代碼首先是給人讀的，而讀代碼的人通常時間緊迫、壓力山大、更想搞懂業(yè)務(wù)邏輯而不是你的架構(gòu)巧思。誠實代碼問的是：下一個人打開這個文件時，能不能在五分鐘內(nèi)明白這里在發(fā)生什么？

有時候答案需要一層抽象。有時候答案就是直接調(diào)用郵件API，在旁邊寫行注釋說明重試邏輯在哪處理。

2008年的那本書不是圣經(jīng)，是特定時間特定背景下的建議。軟件變了，硬件變了，團(tuán)隊結(jié)構(gòu)變了，我們構(gòu)建的東西也變了。規(guī)則本該跟著變。

整潔代碼運(yùn)動最大的諷刺在于：它本意是降低復(fù)雜度，卻催生了一種文化——復(fù)雜度被重新包裝成美德，而質(zhì)疑它的人被當(dāng)成不懂行。

七層抽象發(fā)一封郵件。沒人能完全理解。但代碼很"整潔"。

這真的值得嗎？