為什么寫“簡單的代碼”遠(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è)計”時,不妨問問自己:“我是因為真的需要,還是僅僅因為我能這么做而已?”