5.1 尽早交流和持续沟通能使结构师有较好的成本意识，使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
5.2 结构师如何成功地影响实现：牢记开发人员承担创造性的实现责任，结构师只能提出建议；时刻准备着为所指定的说明建议一种实现方法，准备接受任何其他可行的方法；准备对所建议的改进放弃坚持；听取开发人员在体系结构上改进的建议。
5.3 第二个系统是人们所设计的最危险的系统，通常倾向是过分的进行设计。
5.4 为功能分配一个字节和微秒的优先权值是一个很有价值的规范化方法。
贯彻执行
6.1 即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定一致。
6.2 必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。
6.3 出于精确性的考虑，我们需要形式化设计定义，也需要记叙性定义来加深理解。
6.4 必须采用形式化定义和记叙性定义中的一种作为标准，另一种作为辅助措施。
6.5 如果起初至少有两种以上的实现，体系结构定义会更加整洁和规范。
6.6 项目经理最好的朋友就是他每天需要面对的对手—独立的产品测试机构或小组。
为什么巴比伦塔会失败
7.1 巴比伦塔项目失败是因为缺乏交流以及交流的结果—组织。
7.2 交流：因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现，由于对其他人的假设，团队成员之间的理解开始出现偏差。
7.3 项目工作手册：是对项目必须产生的一系列文档进行组织的一种结构。 项目所有的文档必须是该手册的一部分。 需要尽早和仔细设计工作手册结构。 每一个团队成员应该了解所有的材料。 实时更新至关重要。
7.4 组织架构： 团队组织的目标是为了减少必要的交流和协作量。 为了减少交流，组织结构包括了人力划分和限定职责范围。 权力结构是树状结构，组织中的交流是网状结构。 每个子项目都具有两个领导角色— 产品负责人、技术主管或结构师。
胸有成竹
8.1 仅仅通过对编码部分时间的估计，乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的。
8.2 构建独立小型程序的数据不适用于编程系统项目。
8.3 程序开发呈程序规模的指数增长。
8.4 当使用适当的高级语言时，程序编制的生产率可以提高5倍。
削足适履
9.1 除了运行时间以外，程序所占据的内存空间也是主要开销。特别是对于操作系统，它的很多程序是永久驻留在内存中的。
9.2 软件开发人员必须设立规模目标，控制规模，发明一些减少规模的方法。
9.3 规模预算不仅在占据内存方面是明确的，同时还应该指明程序对磁盘的访问次数。
9.4 规模预算必须与分配的功能相关联，在指明模块大小的同时，确切定义模块的功能。
9.5 在整个实现的过程期间，系统结构师必须确保连贯的系统完整性。
9.6 培养开发人员从系统整体出发，面向用户的态度是软件编程管理人员的最重要职能。
9.7 编程需要技术积累，每个项目需要自己的标准组件库。