軟體開發實踐的24條軍規

　　本文的這些最佳程式設計實踐、開發準則都是偉大的程式設計師的經驗總結。Tim Oxley從網際網路中搜集了這些最佳實踐，並放在了Github上，以供他人檢視和補充。希望這些最佳實踐能夠為你的開發工作帶來一些幫助。 

　　1.  不要構建大型應用

　　構建大型應用的祕訣就是“不要構建大型應用”，也就是把你的應用拆分成若干小應用，然後將這些可測試的小應用組裝到一起。——Justin Meyer，JavaScript MVC作者 

　　2.  注重專案質量

　　當我聽到“匆忙做出了能夠執行的程式碼”，我也許不會去使用這些應用程式，因為它們會逐漸喪失可迭代的能力。——Avdi Grimm 

　　3.  不寫程式碼

　　“Don’t write code”是每一個開發人員都需要學習的最重要的一條準則。目前存在大量重複的、蹩腳的程式碼（跨專案），在很多情況下，開發者甚至不去仔細看看周圍有什麼，他們只是一味地編寫程式碼。 

　　4.  將減少產品中程式碼量作為目標

　　我討厭程式碼，我希望在我們的產品中程式碼儘可能少。——Jack Diederich 

　　5.  保持最少依賴

　　經典格言“不要重新發明輪子”並不適用於火車頭處的輪子（指專案的核心部分）。 

　　6.  停止編寫類

　　“這不應該是一個類”，尤其是在類有兩個方法，且其中一個是建構函式時。任何時候你看到這種情況時，你也許只應該寫一個函式。——Jack Diederich 

　　7.  忘掉新功能，將同樣的東西做得更好

　　開發者容易忽視而使用者通常比較關心的東西是——應用程式中最常用功能的效能和可用性。——Tim Anderson 

　　8.  重新發明輪子

　　發明自己的輪子，可以讓你更深刻地理解輪子如何工作，以及如何才能做得更好。 

　　9.  做容易的事情，而不是難的

• 簡單比複雜好
• 複雜（Complex）比超複雜（complicated）好
• 順序比嵌入好
• 可讀性應當被重視
• 如果你的程式碼實現難以解釋，這不是一個好的實現

　　——The Zen of Python（Python禪宗） 

　　10.  重寫>重構

　　如果你正在更改一個類或方法超過25％的部分，你可以考慮重寫，你的程式碼將會更加整潔。 

　　11.  重構>重寫

　　重寫一個專案的常見藉口： 

• 程式碼很爛
• 我們現在更聰明瞭
• 我們選錯平臺/語言了

　　為什麼重寫（幾乎）不是一個好主意： 

• 它總是需要比你預期更長的時間
• 市場在不斷變化
• 現有客戶會變得沮喪
• 重構也可以清理程式碼
• 你無法控制重寫的程式碼，最後會變成它在控制你

　　12.  你不知道專案將如何增長

　　從一開始你就要承認，你不知道專案會如何增長。一旦你承認這一切，你就會開始防禦性地設計系統……你應該花大部分的時間來考慮介面，而不是實現。——Nicholas Zakas，《高效能JavaScript網站》作者 

　　13.  避免程式碼味道（指程式碼中存在潛在問題）

　　14.  寫單元測試

　　每個程式設計師都知道他們應該為自己的程式碼編寫測試，但很少有人會這樣做。問其“為什麼不呢？”通常會回應“我太忙了。”這很快就會變成了一個惡性迴圈——你感到壓力越大（越忙），你寫的測試就會越少，你的程式碼也會變得不太穩定，你的生產力會越來越低。這樣一來，你的壓力就更大了（工作更忙了）。正是由於這樣的惡性迴圈，導致程式設計師的編碼熱情降低。我們發現，有時一個簡單的測試框架，就可以讓工作有很大的不同。 

　　（沒有單元測試）你不是在重構，你只是正在改變一堆狗屎。——Hamlet D'Arcy 

　　15.  測試驅動開發&控制反轉（Inversion of Control）

　　即使你的程式碼不需要測試，你也應該編寫可測試的程式碼。IoC（控制反轉）可以幫你這樣做。嘗試在測試時注入對測試友好的依賴或模擬例項，並隔離受測試單元。 

　　16.  避免將物件建立與應用程式邏輯混合在一起

　　17.  避免建立技術債務

　　儘管不成熟的程式碼可以正常工作，客戶也完全可以接受，但是最後出現的技術債務將會使你疲憊不堪，整個工作組也有可能會被這些技術債務困在原地。 

　　18.  過早優化是罪惡之源

　　一些程式設計師會浪費大量的時間去思考或擔心程式中非關鍵部分的執行速度，而他們的這些嘗試有可能會對最終的除錯和維護產生負面影響。我們應該忘掉小的效率，在97%的時間內告誡自己“過早優化是罪惡之源”，但是，也一定不能在關鍵的3％上錯過優化機會。 

　　19.  計劃，計劃，計劃

　　首次就做正確的事情比稍後重做的代價要小得多，發現解決問題越早，代價就越小。 

　　夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也。多算勝少算，而況於無算乎！吾以此觀之，勝負見矣。——孫子兵法 

　　計劃是無用的，規劃是無價的。——溫斯頓•丘吉爾 

　　20.  一個不斷學習的程式設計團隊

　　即使一個團隊中的程式設計師平庸、缺乏經驗，但如果他們都為團隊利益而編寫程式碼，就有可能會成為一支偉大的團隊。這一切都要看該團隊是否能夠意識到他們的工作只是寫程式碼或將寫程式碼和學習作為首要目標。——Reginald Braithwaite 

　　21.  不斷評估、完善

　　軟體設計是一個迭代的過程，在一開始不可能什麼都考慮到，需要在之後的過程中通過經驗來不斷完善。而且通常情況下，很少有軟體專案能夠完全按照預期來完成，隨著專案的進展，對於專案的預期也會下降。 

　　22.  什麼是架構

　　你的專案架構反映了什麼？是醫療保健系統、會計系統、庫存管理系統，還是rails、spring/hibernate、ASP？ 

　　軟體產品的架構應該讓所有人都很容易瞭解產品所要達到的目的，並且系統的架構應該反映系統的用例而不是它使用的框架。架構不是（或不應該是）關於框架的內容。架構不應該由框架支援。框架是我們要使用的工具，而不是要符合的架構。如果你的架構基於框架，那麼它就無法基於你的用例。——Uncle Bob Martin，《尖叫的架構（Screaming Architecture）》作者 

　　23.  X-Windows系統設計原則

• 不用增加新的功能，除非沒有它就無法完成一個真正完整的應用程式
• 決定一個系統不是什麼和決定它是什麼同樣重要。你無法滿足世界上所有人的需求，好的做法是，使系統可以以向上相容的方式擴充套件，以便能夠滿足額外需求。
• 比從一個例子中歸納，更壞的是，沒有可歸納的例子。
• 如果你不能完全瞭解一個問題，那麼最好別提供任何解決之道。
• 如果預期要用90%的努力去完成10%的工作，那麼應該用更簡單的辦法解決。
• 儘量避免複雜性
• 提供機制而不是策略，實踐中把使用者方面策略放在使用者手裡。

　　24.  Unix設計原則

• 模組化準則：編寫簡單的模組用清晰的介面把它們連線起來。
• 清晰性準則：清晰性優先於巧妙。
• 組合準則：設計可以和其他程式連線的程式。
• 分離準則：把政策和機制相分離；把介面和引擎相分離。
• 簡單性準則：設計追求簡單性，只在絕對必須時加入複雜性。
• 節儉準則：只在通過原型澄清後才編寫大的程式。
• 透明性準則：設計的可見性使檢查和除錯更容易。
• 健壯性準則：健壯性是透明性和簡單性的孩子。
• 表示準則：將知識包入資料，程式邏輯可以是笨拙和健壯的。
• 最小驚喜準則：在介面設計中，總是遵循最小驚喜準則（總是做令人驚喜的事情）。
• 沉默準則：如果程式沒有重要的輸出，它就應該保持沉默。
• 修復準則：如果你必須出錯，儘可能響亮和快速的出錯。
• 經濟性準則：如果和機器時間比較，程式設計師的時間是昂貴的。
• 生成準則：避免手工程式設計，如果可能，編寫編寫程式的程式。
• 優化準則：在打磨前建立原型，在你優化前先使他工作。
• 多樣性準則：懷疑一切聲稱“只能如此”的說法。
• 擴充套件性準則：為未來設計，因為它往往來的比你想得快。

　　——Eric S. Raymond，《Unix程式設計藝術》作者

　　英文原文：Programming Best Practices Tidbits