軟體開發實踐的24條軍規

　　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編程藝術》作者