你大概已經聽過無數次：“讓代碼保持簡單”。

幾乎每個資深開發者、每本講求整潔代碼的書、每家工程博客都在強調同一個目標：

寫出簡單的代碼。

因為簡單的代碼更易維護、更易閱讀，也通常更高效。

可為什么現實里，還是到處能見到復雜混亂的代碼呢？

原因就在于，“寫簡單的代碼”本身并不簡單。

表面看起來簡單，做起來卻困難

當你看到一段寫得恰到好處的代碼，你會覺得“這不就應該這樣寫嗎？”

仿佛所有邏輯都顯而易見、所有架構都自然而然。

但要達到這種清晰度，往往需要相當多的迭代、經驗和思考。

不少開發者，尤其是初入行時，很容易把“復雜”與“聰明”劃等號。他們會刻意往系統里加各種抽象、擴展性、配置項，覺得這樣很“高級”。他們提前為未來做一堆假設，結果反而把自己陷入凌亂的抽象網絡里。

簡單的代碼則截然不同，它絕不是隨隨便便寫出來的。需要你有：

1. 經驗：寫過并調試過一大堆過度復雜、難維護的代碼后，才會知道要避免什么。
2. 克制：不亂加抽象和配置，其實比往里加功能更難。
3. 明晰的取舍：你無法一次性滿足所有需求。有時候不得不在靈活性、性能或簡潔度之間做犧牲。

復雜的幻象

這其中還存在一種心理錯覺：看到一段復雜的代碼，往往會以為它是在解決一個很復雜的問題。“既然寫得這么復雜，那肯定很高深吧？”其實未必。

有時復雜只是因為作者拿不定主意：

• 不知道哪種方式更好，就都加進去
• “萬一以后要用呢？”就為此多寫一層封裝
  結果系統到處是多余的函數、配置和選項，既難理解又難調試。

常見導致復雜的“坑”

如果想寫簡單的代碼，先要弄清楚代碼為什么會變得復雜。以下幾個是最典型的陷阱：

1. 過度抽象：并不是每個函數都要適配所有可能場景。有時明文寫出具體邏輯，比寫一堆“泛用”但是迷糊的抽象要好。
2. 過早優化：很多人一上來就想把所有功能都做成“可伸縮”的，但實際上可能永遠用不到那些擴展。先解決當前問題比較要緊。
3. 過多層級：在封裝之外又封裝，再包一層外殼——每加一層，對理解和維護都是額外負擔。
4. “功能繁多”卻沒場景：為將來的需求而做的臆想功能，往往會成為累贅。“YAGNI”（You Ain't Gonna Need It）就是勸你別為不確定的需求去寫多余的代碼。
5. 不必要的配置：有些人喜歡把一切都做成可配的，但往往默認值就足夠應付大部分場景。

實用建議：怎樣讓代碼更簡單？

讓代碼保持簡單不代表只寫短代碼，而是要寫更易懂、更直觀的代碼。可以試試：

1. 自解釋式的命名：變量和函數名要能說明做了什么。如果必須要寫大量注釋解釋函數的用途，說明邏輯可能需要拆分或命名需要改進。
2. 限制抽象層級：沒發現真正的復用需求前，先別急著搞抽象工廠、復雜繼承或深層嵌套。
3. 遵循“約定優于配置”：與其自己再寫一堆配置，不如先用主流或社區的最佳實踐，一致性帶來的可維護性往往更高。
4. 持續重構：只要覺得哪塊代碼讀起來“別扭”，就重寫或簡化。讓它保持干凈是一個長期過程。
5. 關注可讀性：想象一下，半年前寫的代碼，今天再看是否能立刻明白？如果答案是否定的，就該考慮如何讓它更清晰。

簡單的代碼，需要“狠心”

寫簡單代碼最難的部分，往往是做取舍。

哪些功能是真的需要可擴展？哪些部分完全可以寫死？這層抽象究竟是在解決實際問題，還是只是在滿足你的“炫技”欲望？

好的開發者有能力排除噪音，剔除不必要的東西，為可維護性和可理解度優先買單。這需要果斷和經驗。

最后的想法

其實人人都能寫出復雜的代碼，因為把想法不停地塞進去最輕松了。
但要把代碼“減負”，只留下必要的核心，這才是真正的挑戰。
簡潔不是起點，而是不斷打磨和舍棄后的成果。
下次你覺得自己開始“過度設計”時，不妨問問自己：“我是因為真的需要，還是僅僅因為我能這么做而已？”