本文的这些最佳编程实践、开发准则都是伟大的程序员的经验总结。Tim Oxley从互联网中搜集了这些最佳实践，并放在了Github上，以供他人查看和补充。希望这些最佳实践能够为你的开发工作带来一些帮助。
10. 重写>重构 如果你正在更改一个类或方法超过25％的部分，你可以考虑重写，你的代码将会更加整洁。 11. 重构>重写 重写一个项目的常见借口：
从一开始你就要承认，你不知道项目会如何增长。一旦你承认这一切，你就会开始防御性地设计系统……你应该花大部分的时间来考虑接口，而不是实现。——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系统设计原则
英文原文：Programming Best Practices Tidbits |
