知名作家Jules Verne道出了一句真理：極簡適用于所有事物。

當今世界，極簡被廣泛應用于各種事物，代碼也不例外。然而令人沮喪的事實是：當前的代碼過于冗長。更準確地說，不必要的代碼太多，已經到了妨礙有效代碼的地步。

也就是說，不必要的代碼本質就是有害的：它會腐爛，需要定期維護，需要找出漏洞。新特征意味著要更新舊代碼。代碼越多，存在漏洞的地方就越多。校驗或編譯所需的時間越長，新員工理解編譯系統所需的時間也越長。

除此之外，代碼是由工程師編寫的。要寫的代碼越多，需要的工程師就越多，進而溝通成本也越高，并進一步促進代碼維護和開發成本的不斷提高。

[[277460]]

解決上述所有問題的一個方法就是減少代碼量。

減少代碼量有很多好處：

• 開發的代碼越少=開發成本越低
• 開發的代碼越少=維護成本越低
• 開發的代碼越少=代碼漏洞越少
• 開發的代碼越少=有效檢測越多

最最重要的一點是：代碼量越少，人們閱讀代碼的概率越高。

以下介紹一些減少代碼量的方法。

你不需要它

你不需要它(You Aren’t Gonna Need It，通常縮寫為YAGNI)是一個極限編程原則，指：

“等你真正要用的時候再編碼，永遠不要因為你猜測以后將會用到而編碼。”

即使你百分百確定之后將會用到某一個特征，也不要現在就編寫代碼。

實行YAGNI原則主要基于兩個原因：

• 第一，避免寫不必要的代碼可以節省時間。
• 第二，猜測或多或少會出錯，而因猜測提前寫下的代碼則會一直在，并損害代碼的整體表現。避免寫不必要的代碼可以使最終完成的代碼性能更好。

YAGNI原則對所有項目管理都是合理有效的。好的代碼設計考慮周到，特征平衡。不好的代碼設計則塞滿了各種糟糕設計，變得運轉不靈，成為“維護的噩夢”。

這帶給我們的經驗法則就是，專注于明確需要的事物，不要被可能需要的事物分心。

[[277461]]

不要寫防彈代碼

防彈代碼指在任何輸入或意外條件下都能起效的完美代碼。

這是一種非常吸引人的想法，特別是對于那些不能容忍代碼在某些場景下失效的高級開發人員。即便如此，編寫或嘗試編寫防彈代碼不僅不切實際，而且不必要，因為世界上的所有事物，包括軟件，都有其局限性。

要試著編寫一個完美的模塊，就要編寫額外的條件，而這將會使代碼變得非常復雜，毀掉編寫代碼的初衷。到時候，模塊會變得更龐大、成本更高，并可能更難維護。

這也解釋了為什么編寫更少代碼的經驗法則是編寫能夠起效的最簡單的代碼。

極限編程闡明了兩個寫簡單代碼的黃金原則：

• 第一，以你認為能夠起效的最簡單的方法。不要搭建太多使人眼花繚亂的超級結構，不要搞花里胡哨的噱頭，只要有效就好。對新特征的代碼進行單元檢測(所有特征都需要這一步)。
• 第二，也是極其重要的一點，重構系統，使其在保留現有所有特征的情況下，盡可能使用最簡單的代碼。遵循“有且僅有一次”原則和其他代碼質量原則，使得系統盡可能地簡單明了。

時刻記住，我們需要的不是最快捷的方法，而是最簡單的結果。因此，首先將現有方法分解為多個部分，保留現有測試用例繼續運行。其次，簡單地修改其中一小部分方法，用于處理下一個測試用例。如此循環。

記住，簡約是極致的優雅。優秀編程的本質在于控制和消除復雜性。

永遠不要讓代碼變得更糟糕

這可以說是開發人員的“希波克拉底誓言”。開發人員常常被建議不要圖省事走捷徑，否則將會導致代碼質量下降，變得更糟糕。

和醫療程序一樣，軟件工程程序具有入侵性和破壞性，其使用的工具和技術也可能是全新的、未經檢測的(或隨意檢測的)。然而不同的是，軟件工程的實踐和采用的工具沒有得到類似醫療資格理事會或食品藥品管理局(FGA)這樣的組織的規范。因此，軟件工程開發者有時會在尚未完全了解風險的情況下對“病人”——即軟件——進行不必要的風險性操作。

在解決問題的過程中，我們所做的有時會得不償失。Steve McConnell在其軟件工程經典著作《代碼大全(Code Complete)》中提到，如果不解決問題的根源，而僅僅局限于問題的表面，往往是弊大于利的，開發者會自我欺騙，讓自己相信這個問題已經解決了。

然而有時候這是很難的。遺留代碼增強了恰到好處地增加功能而又不損害代碼的難度。實際上，把“永遠不要讓代碼變得更糟糕”改成“故意降低代碼質量”更加符合事實。

是的。如果你不知道如何在保持代碼質量不變的情況下更改代碼，那么就在更改之前告知團隊其他成員。重點在于，你是故意降低代碼質量的。

當然，這并不能夠防范不好的代碼，但是可以給你一些時間來思考。經驗告訴我們，人們在無法想到好的解決辦法時，會停止思考，轉而做腦海中想到的第一件事。需要注意的是，我們并不是在要求獲得準許或得到一個更好的結果。

“故意降低代碼質量”的另一個優點在于它可以防范在錯誤的時間發生令人不悅的意外，并且使團隊成員意識到可能出現的問題。這樣，團隊就可以很好地合作，處理這些問題。

[[277462]]

避免不必要的并發性

并發性是一把雙刃劍，應該只在必要的時候使用。

如果源代碼是按順序執行的，那么代碼更容易被理解和調試。但如果使用了并發性，代碼執行可能會出現并行或不規律。這種執行上的差異使得代碼調試變得非常困難。更不用說，它會以多種方式導致程序設計和執行復雜化。由于實行不當的并發性可能導致的問題有：

• 競爭條件(race conditions)：出現預料之外的操作。
• 死鎖(deadlocks)：表格被鎖定，需要等待同步操作推進。
• 資源匱乏(resource starvation)：操作被永久拒絕訪問需要的資源。

世界上最臭名昭著的一個軟件災難就是由并發行使用不當造成的。Therac-25放射治療儀的一個編程問題導致了4個人的死亡。

即便如此，現代編程語言和架構還是提供了多種并發性工具。但是最終決定權還是在開發者手上。開發人員決定了如何、何時、何處使用并發性來達到最好的結果。

最后，不要囤積代碼

強迫性囤積，或者說囤積障礙，特指一種過度獲取、無法或不愿丟棄大量物品，最終導致占用大量生活區域并帶來災難或損害的行為模式。

如果開發者有囤積障礙，他們會牢牢抓住有漏洞甚至是已經廢棄的代碼不放。這樣的開發者永遠不會刪除任何代碼，也拒絕調動代碼。而當你去質問他們時，他們會給出“我們總有一天可能會用到這個代碼”或“我需要這個代碼來執行活動X”，諸如此類的回答。

你是代碼囤積者嗎?你是否以沒有時間為借口而拒絕清理一團糟的代碼?如果你的回答是肯定的，那么你就是一個代碼囤積者，你的工作就是一團亂麻。

囤積是一種非理性行為。如果你不確定代碼的存在是否合理，可以對它進行恰當地標記，以便讓你注意到它，并再稍后重新審視它。最后，定期清理無效的、不需要的代碼。

一個好的編程人員每天都在使自己的代碼變得更好，精益求精。他們的代碼質量會隨著時間的增長而提高。優秀的編程人員總是留下比舊代碼更加簡潔的遺留代碼，而不是一團亂麻。他們的名譽被嵌在代碼中永久保留。

就像Robert Martin說過：真相只存在于代碼之中。