1 . 架构才是影响性能和可伸缩性的决定因素。性能参数是无法简单地通过更换软件，或者“调优”，或者一个底层软件架构来改善的。我们必须在软件的架构设计（或者重新设计）投入更多的精力。
2 . 通过关注问题的真正含义，理顺需求的轻重缓急：把最有价值的需求放在第一位。
3 . 不幸的是，架构师往往容易被抽象的架构所吸引，沉迷于设计过程。
4 . 一行代码比五百行架构说明更有价值。
5. 提前关注性能问题。
6. 先确保解决方案简单可用，再考虑通用性和复用性。
7. 取舍的艺术。
8. 重视不确定性。
如果出现两个合理的选择，那么应该停下来，设法找出介于两者之间，有更低重要性的决策，而不是简单地在两者之中作出选择。了解两者之外还有其他选择（这个选择并不好找），比决策本身更有价值。
9. 记录决策理由。
10. 简单的解决方案比精巧的要好，比尽善尽美的要好的多。
11. 小心好主意，注意它是不是“骆驼鼻子”，它有可能成为项目杀手。
12. 架构师要以自己的编程能力为依托。
13. 弃聪明，求质朴。
14. 事情的发展总是出乎意料。
15. 不要急于求解。
16. 问题刚出现时一般并不起眼，直到后期才会变得严重。
17. 复用的前提：让大家知道它们存在，让大家知道如何用，让大家知道使用后会更好。
18. 太抽象的结构视图不够清晰，太具体的视图不容易理解，我们需要恰如其分。
19. 先尝试，后决策。推迟决策，甚至不做决策。
20. 今天的解决方案会成为明天的问题。
21. 如果你能透过清汤，看到底下硬币上的日期，你就知道架构已臻完成。
22. 优秀软件不是构建出来的，而是培育出来的。在一开始设计庞大的系统几乎没有任何好处。
在一开始设计庞大的系统几乎没有任何好处。前期便要设计庞大的系统，意味着项目会变的庞大无比，而大型项目更可能会失败，更加无法验证，更加脆弱不堪，更容易产生不必要的产物，成本更是无比高昂。因此，无论多么诱人，都要抵制住试图设计出庞大完整的系统，来“满足甚至超过”已知需求和特性期望的想法。要有宏伟的远景，grand vision,但不要有庞大的设计。如何做到这点，确保系统能够演化和具备适应性的最好办法，是从一开始就这样做。引导系统进行演化。设计尽可能小的系统，并推动它向宏伟的远景目标不断演化。