你有沒有試過，正準備給同事解釋一段代碼，講到一半忽然發現——自己也沒太懂？

“這個方法會先調個 helper，然后它會修改全局狀態；除非某個開關關了，我們就改掉默認配置，等等，我把圖翻出來……”

對，這不是系統，這是迷宮。

我給自己定了個鐵律：

如果一個功能用一句話講不清，它就太復雜了。

不是對用戶，不是對老板，而是對你——寫它的那個人。

復雜，常常藏在“必須先懂點背景”的話術里

開發者最愛說的一句是：“不復雜，你只要懂它怎么工作的。”問題恰好在這兒。

如果必須先理解一堆前置知識才能開口描述，那它就不簡單。那是謎題，也許很巧妙；然而，謎題不適合生產。不適合在你離宕機還有 5 分鐘、唯一“真正懂的人”正在休陪產假的時候。

我寫過這種系統，寫完還挺驕傲。

直到有一天，CTO 站在我身后盯著屏幕，我卻連一條可用的 trace都沒有。 最后救我的，是一句話邏輯：

“這個函數找到用戶最近一次購買。” 而不是： “這個函數拉一條事件流，用三種投影重建訂單，除非 legacy flag 還開著……”因此，這就是工具與陷阱的差別。

你講不清的代碼，其實不屬于你

總有個幻想：只要抽象夠優雅、模式夠高級、框架夠熱門，代碼會自解釋。

可現實更多是自我引用：

抽象 A 依賴抽象 B，B 依賴你用 schema 生成的 interface，而這個 schema 還是你從 Slack 里復制出來的。

于是，就是“烏龜疊羅漢”：

到最后，想懂一個點，得把所有點都看一遍；結果是誰也沒真的懂。 我把“難以一句話解釋”當作比多層回調還臭的 code smell，甚至比過度 Redux 化更糟。它明面上看不出來；它讓你以為自己終于搞懂了，于是放松警惕——

然而，未來的你不會；你的同事更不會。

簡單，不等于代碼行數少

我見過10 行的函數也過于復雜；

也見過100 行的文件卻簡單得漂亮——每一段都只做一件事，而且顯而易見。

所以，簡單不是“短”，而是“清楚”。

問問自己：能否一句話描述它在做什么？

試試看：隨機打開一個文件，挑個函數，試著大聲用一句話講出來。 如果你開始停頓、回溯，或者不自覺說出“其實就……” 恭喜，你發現了復雜度泄漏。 “就”是開發者的口頭禪，意思往往是：“我知道這不太說得過去，但希望你先別細看。”

一句話法則（貼在顯示器邊上）

一句話。能過，就過；過不了，立刻重構。 有時意味著拆分； 有時意味著刪掉那個自以為優雅的抽象。盡管如此，它永遠值得： 從此你能說清它做什么、怎么做、為什么——一口氣說完。 下一位接手的人也能（哪怕是幾個月后的你，周一早上宿醉未醒、火燒眉毛時）。

收尾：簡單的本質，是不讓人困惑

這不是要你做極簡苦行僧，拒絕一切框架、只寫 vanilla JS。 這關乎清晰。因此，下次你被代碼細節淹沒時，問自己一句：“我能用一句話解釋它嗎？”如果不能，你還沒寫完。 哪怕測試都綠了——尤其是當測試都綠了。