最好的代碼就是沒有代碼

來自專欄代碼雜談

翻譯自: https://blog.codinghorror.com/the-best-code-is-no-code-at-all/

Rich Skrenta 在他的代碼就是我們的敵人中寫道：

代碼很壞。他會腐爛、他要求周期性維護、他有 bug 了需要花時間找出來。新特性需要修改老代碼。更多的代碼代表更多地方可能藏著 bug、更久的拉取和編譯時間、更長的新員工理解你系統的周期。如果你需要重構，這就會需要你做更多的調整。

工程師們生產代碼。更多代碼代表著需要更多工程師。工程師之間溝通是 n^2 倍開銷，以及當他們的代碼都提交到系統中時你需要增加更多處理能力以及更多預算。所以你應該盡一切可能去提升每一個程序員寫下的代碼的生產力。對於做一件事情，越少的代碼代表著需要招聘更少的人、更小的組織溝通代價。

Rich 暗示的敵人就在上面，但其實真正問題不在於代碼。代碼就像一個新生兒，當他剛降生到這個世界上時不該指責，他是無罪的。代碼不是我們的敵人，你想看看真正的敵人？去看一眼鏡子，那裡有你的答案。

作為軟體開發者，你就是你最壞的敵人。儘早意識到這個問題，儘早改善你自己。

我知道你的意圖是善意的。你我都是。我們是開發者，我們喜歡寫代碼。這是我們的工作。我們從來沒有遇到過三板斧解決不了的問題。但是 Wil Shipley 爭辯我們應該控制我們寫大量代碼的天性。

編碼的基本性質就是，作為程序員，我們的任務就是認識到我們做出的每一個決定都是一種權衡。成為一個程序員大師就是要理解這種權衡的本質，並且在我們所有寫下的代碼中意識到這些權衡。

在編碼中，你有很多維度對代碼評級：

- 簡潔度

- 特性程度

- 執行速度

- 編碼時間

- 穩健性

- 靈活性

現在記住這些維度都是互相對立的。你能花三天時間寫一個漂亮且快速度的路由。你提升了兩個維度，但是你需要花費三天的時間，因此「編碼時間」卻降低了。

那麼什麼時候值得這樣去做？我們如何去決策這些決定？答案結果證明非常理智，非常簡單易記沒有人聽過的：從簡潔開始，僅當必要時根據測試要求增加其他維度。

我不能同意更多。當我規勸開發者寫小一點的代碼時，我給過相似的建議。我不是在談論用盡一切書中的辦法去壓縮代碼到更小的物理體積的荒謬比賽。我說的是使用靠譜的策略去減少一個程序員所需要去理解一個系統如何工作的的代碼體積。這裡有一個例子：

if (s == String.Empty)if (s == 「")

這個例子看上去後者更好，因為字數來說更少。然而我幾乎可以肯定會遇到那些聲嘶力竭打擊我的開發人員，因為他們相信 String.Empty 因為某種原因對編譯器更加友好。就好像我關心這個問題，或者有人關心這個問題一樣。

讓大部分開發者意識到這個問題很難，因為他們如此喜歡編碼。但是最好的代碼就是沒有代碼。每一行新代碼都是你給這個世界一個新的待調試、待理解以及待支持的問題。每次你寫新代碼前，你因該只有當你在極其被迫不情願和耗盡所有其他選項。代碼是我們的敵人因為我們程序員寫了忒特么多的代碼。如果你不能做到不寫代碼，至少你要能保持簡潔。

如果你真的喜歡寫代碼 - 真的，真的喜歡寫代碼，你就會喜歡寫儘可能少的代碼。