英文原文：Programming Best Practices Tidbits 編譯：王果 （2013年發表於CSDN資訊）
本文的這些最佳編程實踐、開發準則都是偉大的程序員的經驗總結。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）好
- 順序比嵌入好
- 可讀性應當被重視
- 如果你的代碼實現難以解釋，這不是一個好的實現
10. 重寫>重構
如果你正在更改一個類或方法超過25％的部分，你可以考慮重寫，你的代碼將會更加整潔。
11. 重構>重寫
重寫一個項目的常見藉口：
- 代碼很爛
- 我們現在更聰明瞭
- 我們選錯平臺/語言了
- 它總是需要比你預期更長的時間
- 市場在不斷變化
- 現有客戶會變得沮喪
- 重構也可以清理代碼
- 你無法控制重寫的代碼，最後會變成它在控制你
從一開始你就要承認，你不知道項目會如何增長。一旦你承認這一切，你就會開始防禦性地設計系統……你應該花大部分的時間來考慮接口，而不是實現。——NicholasZakas，《高性能JavaScript網站》作者
13. 避免代碼味道（指代碼中存在潛在問題）
14. 寫單元測試
每個程序員都知道他們應該爲自己的代碼編寫測試，但很少有人會這樣做。問其“爲什麼不呢？”通常會迴應“我太忙了。”這很快就會變成了一個惡性循環——你感到壓力越大（越忙），你寫的測試就會越少，你的代碼也會變得不太穩定，你的生產力會越來越低。這樣一來，你的壓力就更大了（工作更忙了）。正是由於這樣的惡性循環，導致程序員的編碼熱情降低。我們發現，有時一個簡單的測試框架，就可以讓工作有很大的不同。
（沒有單元測試）你不是在重構，你只是正在改變一堆狗屎。——Hamlet D'Arcy
15. 測試驅動開發&控制反轉（Inversion of Control）
即使你的代碼不需要測試，你也應該編寫可測試的代碼。IoC（控制反轉）可以幫你這樣做。嘗試在測試時注入對測試友好的依賴或模擬實例，並隔離受測試單元。
16. 避免將對象創建與應用程序邏輯混合在一起
17. 避免創建技術債務
儘管不成熟的代碼可以正常工作，客戶也完全可以接受，但是最後出現的技術債務將會使你疲憊不堪，整個工作組也有可能會被這些技術債務困在原地。
18. 過早優化是罪惡之源
一些程序員會浪費大量的時間去思考或擔心程序中非關鍵部分的運行速度，而他們的這些嘗試有可能會對最終的調試和維護產生負面影響。我們應該忘掉小的效率，在97%的時間內告誡自己“過早優化是罪惡之源”，但是，也一定不能在關鍵的3％上錯過優化機會。
19. 計劃，計劃，計劃
首次就做正確的事情比稍後重做的代價要小得多，發現解決問題越早，代價就越小。
夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也。多算勝少算，而況於無算乎！吾以此觀之，勝負見矣。——孫子兵法
計劃是無用的，規劃是無價的。——溫斯頓•丘吉爾
20. 一個不斷學習的編程團隊
即使一個團隊中的程序員平庸、缺乏經驗，但如果他們都爲團隊利益而編寫代碼，就有可能會成爲一支偉大的團隊。這一切都要看該團隊是否能夠意識到他們的工作只是寫代碼或將寫代碼和學習作爲首要目標。——ReginaldBraithwaite
21. 不斷評估、完善
軟件設計是一個迭代的過程，在一開始不可能什麼都考慮到，需要在之後的過程中通過經驗來不斷完善。而且通常情況下，很少有軟件項目能夠完全按照預期來完成，隨着項目的進展，對於項目的預期也會下降。
22. 什麼是架構
你的項目架構反映了什麼？是醫療保健系統、會計系統、庫存管理系統，還是rails、spring/hibernate、ASP？
軟件產品的架構應該讓所有人都很容易瞭解產品所要達到的目的，並且系統的架構應該反映系統的用例而不是它使用的框架。架構不是（或不應該是）關於框架的內容。架構不應該由框架支持。框架是我們要使用的工具，而不是要符合的架構。如果你的架構基於框架，那麼它就無法基於你的用例。——UncleBob Martin，《尖叫的架構（Screaming Architecture）》作者
23. X-Windows系統設計原則
- 不用增加新的功能，除非沒有它就無法完成一個真正完整的應用程序
- 決定一個系統不是什麼和決定它是什麼同樣重要。你無法滿足世界上所有人的需求，好的做法是，使系統可以以向上兼容的方式擴展，以便能夠滿足額外需求。
- 比從一個例子中歸納，更壞的是，沒有可歸納的例子。
- 如果你不能完全瞭解一個問題，那麼最好別提供任何解決之道。
- 如果預期要用90%的努力去完成10%的工作，那麼應該用更簡單的辦法解決。
- 儘量避免複雜性
- 提供機制而不是策略，實踐中把用戶方面策略放在用戶手裏。
- 模塊化準則：編寫簡單的模塊用清晰的接口把它們連接起來。
- 清晰性準則：清晰性優先於巧妙。
- 組合準則：設計可以和其他程序連接的程序。
- 分離準則：把政策和機制相分離；把接口和引擎相分離。
- 簡單性準則：設計追求簡單性，只在絕對必須時加入複雜性。
- 節儉準則：只在通過原型澄清後才編寫大的程序。
- 透明性準則：設計的可見性使檢查和除錯更容易。
- 健壯性準則：健壯性是透明性和簡單性的孩子。
- 表示準則：將知識包入數據，程序邏輯可以是笨拙和健壯的。
- 最小驚喜準則：在界面設計中，總是遵循最小驚喜準則（總是做令人驚喜的事情）。
- 沉默準則：如果程序沒有重要的輸出，它就應該保持沉默。
- 修復準則：如果你必須出錯，儘可能響亮和快速的出錯。
- 經濟性準則：如果和機器時間比較，程序員的時間是昂貴的。
- 生成準則：避免手工編程，如果可能，編寫編寫程序的程序。
- 優化準則：在打磨前建立原型，在你優化前先使他工作。
- 多樣性準則：懷疑一切聲稱“只能如此”的說法。
- 擴展性準則：爲未來設計，因爲它往往來的比你想得快。
英文原文：Programming Best Practices Tidbits