1 打好基础

1）软件构建

  “构建”就是指创建事物过程中动手的那些部分。

  软件构建中的构建只要活动就是编码与测试。需求分析和架构设计是这之前完成的基础工作，系统测试是后续工作。

2）用隐喻来更充分的立即软件开发

  通过你不打理解的东西和一些你较为理解的东西比较，你可以对不理解的东西产生更为深刻的理解。

  模型的威力在于其生动性，让你能够把握整个概念。

  各种软件隐喻：写作代码(太简单，从头先到尾)；培植系统(一点点增加)；构造软件(暗示和软件开发的存在诸多阶段，计划，准备等。)

3）三思而后行
  架构的典型组成部分。
  程序组织 系统架构首先要以概括的形式对有关系统做一个综述。架构应该定义程序的主要构造块，每个构造块实现一个高层功能。应该定义每个构造块的通信规则。对于每个  构造块，架构应该描述它能直接使用哪些构造块，能间接使用，不能使用哪些。
  主要类 架构无需详细说明系统中每个类。瞄准80/20法则。
  数据设计 架构应该描述所用到的主要文件和数据表的设计。它应该描述曾经考虑过的其他方案，并说明没有做出选择的原因。
  业务规则 如果架构依赖于某些特定的业务规则，那么它就应该详细描述这些规则。
  用户界面设计
  资源管理 架构应该描述一份管理稀缺资源的计划。稀缺资源包括数据连接，线程，句柄，内存等。
  安全性 架构应该描述实现设计层和代码层面的安全性方法。在制定编码规范的时候要时刻应该把安全性牢记在心，包括处理缓冲区的方法，处理非授信数据(用户输入，配置文件和其他外部接口输入的数据)的规则，加密，错误消息的细致程度，保护内存中的秘密数据，以及其他事项。
  性能 定义性能目标，性能目标也应该详细定义资源(速度，内存，成本)之间的优先顺序。空间和时间预算等。
  可伸缩性 满足未来需求的能力。
  输入输出 读取策略是先做，后做还是及时做。
  错误处理 错误是进行纠正还是仅仅检测；主动还是被动；如何传播；处理机制等。
  容错性
  关于"买"还是"造"的决策 如果架构不采用现货供应的组件，那么就应该说明"自己定制的在哪些方面胜过现成的"。
 
  架构的总体质量 架构的目标应该清除的表述。以系统的可更改行为首要目标的设计，以及性能方面是不同的。架构应该描述所有主要决策的动机。优秀软件架构很大程度上是与机器和编程语言无关的。架构应该明确指出有风险的区域，为什么有风险。