軟體開發實踐的24條軍規

轉自: http://zz563143188.iteye.com/blog/1844388

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

1.  不要建構大型應用

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程式設計藝術》作者 若轉載請注明出處！若有疑問，請回複交流！