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设计原则

模块化准则：编写简单的模块用清晰的接口把它们连接起来。

清晰性准则：清晰性优先于巧妙。

组合准则：设计可以和其他程序连接的程序。

分离准则：把政策和机制相分离；把接口和引擎相分离。

简单性准则：设计追求简单性，只在绝对必须时加入复杂性。

节俭准则：只在通过原型澄清后才编写大的程序。

透明性准则：设计的可见性使检查和除错更容易。

健壮性准则：健壮性是透明性和简单性的孩子。

表示准则：将知识包入数据，程序逻辑可以是笨拙和健壮的。

最小惊喜准则：在界面设计中，总是遵循最小惊喜准则（总是做令人惊喜的事情）。

沉默准则：如果程序没有重要的输出，它就应该保持沉默。

修复准则：如果你必须出错，尽可能响亮和快速的出错。

经济性准则：如果和机器时间比较，程序员的时间是昂贵的。

生成准则：避免手工编程，如果可能，编写编写程序的程序。

优化准则：在打磨前建立原型，在你优化前先使他工作。

多样性准则：怀疑一切声称“只能如此”的说法。

扩展性准则：为未来设计，因为它往往来的比你想得快。