一句話說不清的代碼,十個補丁也救不了
你有沒有試過,正準備給同事解釋一段代碼,講到一半忽然發現——自己也沒太懂?
“這個方法會先調個 helper,然后它會修改全局狀態;除非某個開關關了,我們就改掉默認配置,等等,我把圖翻出來……”
對,這不是系統,這是迷宮。
我給自己定了個鐵律:
如果一個功能用一句話講不清,它就太復雜了。
不是對用戶,不是對老板,而是對你——寫它的那個人。
復雜,常常藏在“必須先懂點背景”的話術里
開發者最愛說的一句是:“不復雜,你只要懂它怎么工作的。”問題恰好在這兒。
如果必須先理解一堆前置知識才能開口描述,那它就不簡單。那是謎題,也許很巧妙;然而,謎題不適合生產。不適合在你離宕機還有 5 分鐘、唯一“真正懂的人”正在休陪產假的時候。
我寫過這種系統,寫完還挺驕傲。
直到有一天,CTO 站在我身后盯著屏幕,我卻連一條可用的 trace都沒有。 最后救我的,是一句話邏輯:
“這個函數找到用戶最近一次購買。” 而不是: “這個函數拉一條事件流,用三種投影重建訂單,除非 legacy flag 還開著……”因此,這就是工具與陷阱的差別。
你講不清的代碼,其實不屬于你
總有個幻想:只要抽象夠優雅、模式夠高級、框架夠熱門,代碼會自解釋。
可現實更多是自我引用:
抽象 A 依賴抽象 B,B 依賴你用 schema 生成的 interface,而這個 schema 還是你從 Slack 里復制出來的。
于是,就是“烏龜疊羅漢”:
到最后,想懂一個點,得把所有點都看一遍;結果是誰也沒真的懂。 我把“難以一句話解釋”當作比多層回調還臭的 code smell,甚至比過度 Redux 化更糟。它明面上看不出來;它讓你以為自己終于搞懂了,于是放松警惕——
然而,未來的你不會;你的同事更不會。
簡單,不等于代碼行數少
我見過10 行的函數也過于復雜;
也見過100 行的文件卻簡單得漂亮——每一段都只做一件事,而且顯而易見。
所以,簡單不是“短”,而是“清楚”。
問問自己:能否一句話描述它在做什么?
試試看:隨機打開一個文件,挑個函數,試著大聲用一句話講出來。 如果你開始停頓、回溯,或者不自覺說出“其實就……” 恭喜,你發現了復雜度泄漏。 “就”是開發者的口頭禪,意思往往是:“我知道這不太說得過去,但希望你先別細看。”
一句話法則(貼在顯示器邊上)
一句話。能過,就過;過不了,立刻重構。 有時意味著拆分; 有時意味著刪掉那個自以為優雅的抽象。盡管如此,它永遠值得: 從此你能說清它做什么、怎么做、為什么——一口氣說完。 下一位接手的人也能(哪怕是幾個月后的你,周一早上宿醉未醒、火燒眉毛時)。
收尾:簡單的本質,是不讓人困惑
這不是要你做極簡苦行僧,拒絕一切框架、只寫 vanilla JS。 這關乎清晰。因此,下次你被代碼細節淹沒時,問自己一句:“我能用一句話解釋它嗎?”如果不能,你還沒寫完。 哪怕測試都綠了——尤其是當測試都綠了。


























