程序員最重要的就是學會「不寫代碼」

對什麼說「不」

學會說「不」是一個好的開端。

可是究竟是對什麼說「不」，又是何時適合說「不」呢？

這的確是大多數程序員，甚至是那些高級程序員都很容易混淆的一個重點。

做爲一名程序員，編寫代碼無疑是你職業中最重要的部分。在你的編程生涯中，你不可避免的地將會處理各類關於不一樣類型代碼的請求。而每一個請求均可能會迫使你作出一些艱難的決定。這些看上去一切正常，彷佛也沒什麼錯。畢竟，這是全部人對你的指望：做爲程序員就該編寫代碼。然而，這裏有一個問題：你是否應該編寫向你請求的全部代碼？

這個問題給咱們引入了一個程序員所能學到最重要的技能：

知道何時不編碼多是程序員所能學到最重要的技能。——《可讀代碼的藝術》

對上面這句話，我徹底贊成。這是爲何呢？

編程是解決問題的一門藝術。所以，天然而然地，程序員成爲了問題解決者。做爲程序員，當咱們面前有一個新問題有待解決，或由於任何其餘緣由須要咱們寫出代碼行時，咱們會由於使命感而感到興奮。

有這種興奮也是再正常不過的，畢竟咱們是程序員，咱們就是喜歡寫代碼。

然而，對編寫代碼這件事過於興奮就會讓咱們變得盲目。這種情緒會讓咱們忽視了一些重要的事實，而這些事實可能致使更大的問題，讓咱們在將來不得再也不去解決這些更嚴重的問題。

那麼，咱們每每容易忽略哪些重要的事實呢？

你寫的每一行代碼都是：

必須被其餘程序員閱讀和理解的代碼

必須被測試和調試的代碼

會增長軟件缺陷的代碼

可能會在未來引入新 bug 的代碼

正如 Rich Skrenta 所寫的，代碼是咱們的敵人：

代碼可謂是邪惡的。代碼會腐爛。代碼須要按期維護。它們老是包含有待發現的 bug。而新特性的添加老是意味着舊代碼必須進行調整。

代碼量越大，bug 所能藏身的地方就越多，且 checkout 或編譯代碼所需的時間就越長，而新員工理解這個系統所須要的時間就越長。這還意味着，若是你須要重構代碼，須要挪移更多東西。

此外，更多的代碼一般意味着程序擁有更少的靈活性和更少的功能。這一點乍一看是違反直覺的，但確實不少時候，較之一個才華平庸的程序員所編寫的冗長混亂的代碼，一個簡單優雅的解決方案能運行更快，且其功能會更通用。

代碼都是由程序員編寫的。因此編寫更多的代碼每每須要更多的程序員。而程序員之間的溝通成本是以 n²的速度增加的，而後，這些程序員寫的全部代碼都添加到系統，在擴大系統功能的同時，也會增長整個軟件工程的運營成本。

我說的這些都是真的，難道不是嗎？因此，那些用他們的生產效率和編程思惟來激勵你的偉大程序員們，都是那些知道何時該說「不」，何時不編程的人。易於維護、持續壽命長、不斷幫助用戶實現功能的那種軟件，應該不包含任何沒必要要的代碼行。

最好的代碼實際上是沒有代碼，而最有效率的程序員知道何時不該該編碼。