《高效能程式員的修煉》一大道至簡

本節書摘來異步社群《高效能程式員的修煉》一書中的第3章，作者： 【美】jeff atwood 譯者： 陸其明 , 張健 責編： 陳冀康, 更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

高效能程式員的修煉

作者在twitter上發的一條短訊：

“你永遠都有簡化的空間。”

11:29 am – 2012-5-21

rich skrenta在“code is our enemy”（代碼是我們的敵人）一文中是這麼說的：

代碼不是什麼好東西。代碼會随着時間的推移慢慢腐爛。代碼需要周期性的維護。代碼裡還藏有bug。新增功能意味着舊的代碼需要被修改。你的代碼越多，bug能藏身的地方就越多，遷出（checkout）或者編譯的時間也就越長，新員工了解你的系統所需要的時間也就越長。如果你不得不重構代碼，那麼你需要調整的地方會更多。

代碼是工程師制造出來的。如果要寫更多的代碼，那就需要更多的工程師。衆多工程師之間有n2的溝通成本。他們在擴充功能時加進系統的所有代碼，也将增加整個系統的成本。你應該盡一切可能去提高每個程式員在代碼表現力方面的能力，以使用更少的代碼來完成同樣的事情（甚至可能做得更好）。你雇用的程式員越少，組織溝通成本也就越低。

rich在這裡給出了一些線索，但是真正的問題不在代碼。代碼就像一個新生兒，在被帶到這個世界的時候，它是無辜而無可非議的。代碼不是我們的敵人。你想看看真正的敵人嗎？去照一照鏡子吧。問題就在那裡！

作為一個軟體開發者，你就是自己最大的敵人。你越早認識到這點，你的境況就會越好。

我知道你抱有極大的善意。大家都一樣。我們是軟體開發者；我們熱愛編碼。那就是我們每天的工作。給我們一些強力膠帶、一個簡易衣架，再加上一小撮代碼，我們總能解決任何問題。但是，will shipley卻認為，我們應該控制住這種寫上一大堆代碼的自然傾向：

作為程式員，我們的任務是要意識到，我們所做的每個決定都是一個折中——這就是編碼的本質。要想成為程式設計大師，那就要了解這些折中的本質，并且在我們編寫的任何代碼中都善加處置。

在編碼過程中，你可以從很多元度去評價你的代碼：

代碼簡潔度；

功能的完整性；

執行速度；

編碼所花費的時間；

健壯性；

靈活性。

記住，這些次元互相之間都是對立的。你可以花上3天時間寫一個非常美觀而迅捷的程式，這樣雖然在兩個次元上獲得了提高，但是因為你花了3天的時間，是以在“編碼所花費的時間”這個次元上就落後了很多。

那麼，什麼時候這樣做才是值得的呢？我們該如何做這些決定呢？其實，答案非常合乎情理，也很簡單，但就是從來沒有人好好遵從：從簡潔開始，然後依據測試的結果按需提升其他的次元。

對此我非常贊同！我曾在“code smaller”一文中勸誡開發者們編寫更小的代碼。我給出的建議其實異曲同工。但不要走極端！我并不想挑起一場“reductio ad absurdum1”競賽：我們用盡書上的聰明技巧，讓代碼能夠塞進更小的實體空間。我想要的是一個實用而明智的政策，以縮減一個程式員在想要了解程式的工作原理時所需閱讀的代碼量。這裡有個很小的例子，以進一步說明我想表達的意思：

對我而言，後面的那個顯然更好一些，因為它更為簡潔。然而，我幾乎可以斷定，一定會有開發人員跳出來與我争辯，可能還要“血戰到底”，因為他們深信這個啰唆的string.empty對編譯器來說更為友好——真是莫名其妙！說得我好像在乎這個一樣。好像真有人在乎這個一樣！

對于絕大多數軟體開發者而言，承認這個事實是很痛苦的，因為他們是那麼熱愛代碼。但是，最好的代碼就是完全沒有代碼（所謂“大道至簡”）。每一行你欣然帶到這個世界來的新代碼都需要被調試，需要被其他開發者閱讀和了解，并且被維護和支援。每當你需要寫代碼的時候，你都應該很不情願但又迫不得已，因為你已經證明其他所有的方法都無濟于事。之是以有人說“代碼是我們的敵人”，正是因為我們當中的很多程式員寫了太多太多的糟糕代碼。然而，如果你不得不寫代碼，你也必須從簡潔開始。

如果你熱愛編碼——而且愛得情真意切——那你就應該惜墨如金。