20.  一个不断学习的编程团队

即使一个团队中的程序员平庸、缺乏经验，但如果他们都为团队利益而编写代码，就有可能会成为一支伟大的团队。这一切都要看该团队是否能够意识到他们的工作只是写代码或将写代码和学习作为首要目标。——Reginald Braithwaite 

21.  不断评估、完善

软件设计是一个迭代的过程，在一开始不可能什么都考虑到，需要在之后的过程中通过经验来不断完善。而且通常情况下，很少有软件项目能够完全按照预期来完成，随着项目的进展，对于项目的预期也会下降。 

22.  什么是架构

你的项目架构反映了什么？是医疗保健系统、会计系统、库存管理系统，还是rails、spring/hibernate、ASP？ 

软件产品的架构应该让所有人都很容易了解产品所要达到的目的，并且系统的架构应该反映系统的用例而不是它使用的框架。架构不是（或不应该是）关于框架的内容。架构不应该由框架支持。框架是我们要使用的工具，而不是要符合的架构。如果你的架构基于框架，那么它就无法基于你的用例。——Uncle Bob Martin，《尖叫的架构（Screaming Architecture）》作者 

23.  X-Windows系统设计原则

不用增加新的功能，除非没有它就无法完成一个真正完整的应用程序

决定一个系统不是什么和决定它是什么同样重要。你无法满足世界上所有人的需求，好的做法是，使系统可以以向上兼容的方式扩展，以便能够满足额外需求。

比从一个例子中归纳，更坏的是，没有可归纳的例子。

如果你不能完全了解一个问题，那么最好别提供任何解决之道。

如果预期要用90%的努力去完成10%的工作，那么应该用更简单的办法解决。

尽量避免复杂性。

提供机制而不是策略，实践中把用户方面策略放在用户手里。

24.  Unix设计原则

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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