為什么寫“簡單的代碼”遠(yuǎn)比想象中難
你大概已經(jīng)聽過無數(shù)次：“讓代碼保持簡單”。
幾乎每個資深開發(fā)者、每本講求整潔代碼的書、每家工程博客都在強調(diào)同一個目標(biāo)：
寫出簡單的代碼。
因為簡單的代碼更易維護、更易閱讀，也通常更高效。
可為什么現(xiàn)實里，還是到處能見到復(fù)雜混亂的代碼呢？
原因就在于，“寫簡單的代碼”本身并不簡單。
表面看起來簡單，做起來卻困難
當(dāng)你看到一段寫得恰到好處的代碼，你會覺得“這不就應(yīng)該這樣寫嗎？”
仿佛所有邏輯都顯而易見、所有架構(gòu)都自然而然。
但要達到這種清晰度，往往需要相當(dāng)多的迭代、經(jīng)驗和思考。
不少開發(fā)者，尤其是初入行時，很容易把“復(fù)雜”與“聰明”劃等號。他們會刻意往系統(tǒng)里加各種抽象、擴展性、配置項，覺得這樣很“高級”。他們提前為未來做一堆假設(shè)，結(jié)果反而把自己陷入凌亂的抽象網(wǎng)絡(luò)里。
簡單的代碼則截然不同，它絕不是隨隨便便寫出來的。需要你有：
- 經(jīng)驗：寫過并調(diào)試過一大堆過度復(fù)雜、難維護的代碼后，才會知道要避免什么。
- 克制：不亂加抽象和配置，其實比往里加功能更難。
- 明晰的取舍：你無法一次性滿足所有需求。有時候不得不在靈活性、性能或簡潔度之間做犧牲。
復(fù)雜的幻象
這其中還存在一種心理錯覺：看到一段復(fù)雜的代碼，往往會以為它是在解決一個很復(fù)雜的問題。“既然寫得這么復(fù)雜，那肯定很高深吧？”其實未必。
有時復(fù)雜只是因為作者拿不定主意：
- 不知道哪種方式更好，就都加進去
- “萬一以后要用呢？”就為此多寫一層封裝
結(jié)果系統(tǒng)到處是多余的函數(shù)、配置和選項，既難理解又難調(diào)試。
常見導(dǎo)致復(fù)雜的“坑”
如果想寫簡單的代碼，先要弄清楚代碼為什么會變得復(fù)雜。以下幾個是最典型的陷阱：
- 過度抽象：并不是每個函數(shù)都要適配所有可能場景。有時明文寫出具體邏輯，比寫一堆“泛用”但是迷糊的抽象要好。
- 過早優(yōu)化：很多人一上來就想把所有功能都做成“可伸縮”的，但實際上可能永遠(yuǎn)用不到那些擴展。先解決當(dāng)前問題比較要緊。
- 過多層級：在封裝之外又封裝，再包一層外殼——每加一層，對理解和維護都是額外負(fù)擔(dān)。
- “功能繁多”卻沒場景：為將來的需求而做的臆想功能，往往會成為累贅?！癥AGNI”（You Ain't Gonna Need It）就是勸你別為不確定的需求去寫多余的代碼。
- 不必要的配置：有些人喜歡把一切都做成可配的，但往往默認(rèn)值就足夠應(yīng)付大部分場景。
實用建議：怎樣讓代碼更簡單？
讓代碼保持簡單不代表只寫短代碼，而是要寫更易懂、更直觀的代碼。可以試試：
- 自解釋式的命名：變量和函數(shù)名要能說明做了什么。如果必須要寫大量注釋解釋函數(shù)的用途，說明邏輯可能需要拆分或命名需要改進。
- 限制抽象層級：沒發(fā)現(xiàn)真正的復(fù)用需求前，先別急著搞抽象工廠、復(fù)雜繼承或深層嵌套。
- 遵循“約定優(yōu)于配置”：與其自己再寫一堆配置，不如先用主流或社區(qū)的最佳實踐，一致性帶來的可維護性往往更高。
- 持續(xù)重構(gòu)：只要覺得哪塊代碼讀起來“別扭”，就重寫或簡化。讓它保持干凈是一個長期過程。
- 關(guān)注可讀性：想象一下，半年前寫的代碼，今天再看是否能立刻明白？如果答案是否定的，就該考慮如何讓它更清晰。
簡單的代碼，需要“狠心”
寫簡單代碼最難的部分，往往是做取舍。
哪些功能是真的需要可擴展？哪些部分完全可以寫死？這層抽象究竟是在解決實際問題，還是只是在滿足你的“炫技”欲望？
好的開發(fā)者有能力排除噪音，剔除不必要的東西，為可維護性和可理解度優(yōu)先買單。這需要果斷和經(jīng)驗。
最后的想法
其實人人都能寫出復(fù)雜的代碼，因為把想法不停地塞進去最輕松了。
但要把代碼“減負(fù)”，只留下必要的核心，這才是真正的挑戰(zhàn)。
簡潔不是起點，而是不斷打磨和舍棄后的成果。
下次你覺得自己開始“過度設(shè)計”時，不妨問問自己：“我是因為真的需要，還是僅僅因為我能這么做而已？”
