作者在Twitter上發的一條推：“你永遠都有簡化的空間。”
Rich Skrenta在“Code is our enemy”（程式碼是我們的敵人）一文中是這麼說的：
程式碼不是什麼好東西。程式碼會隨著時間的推移慢慢腐爛。程式碼需要週期性的維護。程式碼裡還藏有bug。新增功能意味著舊的程式碼需要被修改。你的程式碼越多，bug能藏身的地方就越多，遷出（check out）或者編譯的時間也就越長，新員工理解你的系統所需要的時間也就越長。如果你不得不進行程式碼重構，那麼你需要調整的地方還有更多。
程式碼是工程師製造出來的。如果要寫更多的程式碼，那就需要更多的工程師。眾多工程師之間有n2的溝通成本。他們在擴充套件功能時加進系統的所有程式碼，也將增加整個系統的成本。你應該盡一切可能去提高每個程式設計師在程式碼表現力方面的能力，以使用更少的程式碼來完成同樣的事情（甚至可能做得更好）。你僱用的程式設計師越少，組織溝通成本也就越低。
Rich在這裡給出了一些線索，但是真正的問題不在程式碼。程式碼就像一個新生嬰兒，在被帶到這個世界來的時候，它是無辜而無可非議的。程式碼不是我們的敵人。你想看看真正的敵人嗎？去照一照鏡子吧。那裡就是“你”的問題。就在那裡！
作為一個軟體開發者，你就是你自己最大的敵人。你越早認識到這點，你的境況就會越好。
我知道你抱有極大的善意。大家都一樣。我們是軟體開發者；我們熱愛編碼。那就是我們每天的工作。給我們一些強力膠帶、一個簡易衣架，再加上一小撮程式碼，我們總能解決任何問題。但是，Will Shipley卻認為，我們應該控制住這種寫上一大堆程式碼的自然傾向：
作為程式設計師，我們的任務是要意識到，我們所做的每個決定都是一個折中——這就是編碼的本質。要想成為程式設計大師，那就要理解這些折中的本質，並且在我們編寫的任何程式碼中都善加處置。
在編碼過程中，你可以從很多維度去評價你的程式碼：
- 程式碼簡潔度
- 功能的完整性
- 執行速度
- 編碼所花費的時間
- 健壯性
- 靈活性
記住，這些維度相互之間都是對立的。你可以花上3天時間寫一個非常美觀而迅捷的程式，這樣你在兩個維度上獲得了提高，但是因為你花了3天的時間，所以在“編碼所花費的時間”這個維度上就落後了很多。
那麼，在什麼時候這樣做才是值得的呢？我們該如何做這些決定呢？其實，答案非常合乎情理，也很簡單，但就是從來沒有人好好遵從：從簡潔開始，然後依據測試的結果按需提升其他的維度。
對此我非常贊同！我曾在“Code Smaller”一文中勸誡開發者們編寫更小的程式碼。我給出的建議其實異曲同工。但不要走極端！我並不想挑起一場“reductio ad absurdum”競賽：我們用盡書上所有的聰明技巧，讓程式碼能夠塞進更小的物理空間。我想要的是一個實用而明智的策略，以縮減一個程式設計師在想要了解程式的工作原理時所須閱讀的程式碼量。我這裡有個很小的例子，以進一步說明我想表達的意思：
譯者注：reductioad absurdum意指反證法，是拉丁語中的“轉化為不可能”。反證法（又稱歸謬法、背理法）是一種論證方式，它首先假設某命題不成立（即在原命題的條件下，結論不成立），然後推理出明顯矛盾的結果，從而下結論說原假設不成立，原命題得證。
if（s==String.Empty） if（s==””）
對我而言，後面的那個顯然更好一些，因為它更為簡潔。然而，我幾乎可以斷定，一定會有開發人員跳出來與我爭辯，可能還要“血戰到底”，因為他們深信這個囉嗦的String.Empty對編譯器來說更為友好（真是莫名其妙！）。說得我好像在乎這個一樣。好像真有人在乎這個一樣！
對於絕大多數軟體開發者而言，承認這個事實是很痛苦的，因為他們是那麼地熱愛程式碼。但是，最好的程式碼就是完全沒有程式碼（所謂“大道至簡”）。每一行你欣然帶到這個世界來的新程式碼都需要被除錯，需要被其他開發者閱讀和理解，並且被維護和支援。每當你需要新寫程式碼的時候，你都應該很不情願、但又迫不得已，因為你已經證明其他所有的方法都無濟於事。之所以有人說“程式碼是我們的敵人”，正是因為我們當中的很多程式設計師寫了太多太多的糟糕程式碼。然而，如果你不得不寫程式碼，你也須從簡潔開始。
如果你熱愛編碼——而且愛得情真意切——那你就應該惜墨如金。
本文轉載自：http://www.itjhwd.com/cyxddzj/