第四章
- 概念完整性是系统设计中最重要的考虑因素。
- 功能与理解上的复杂程度的比值才是系统设计的最终测试标准，而不是仅仅是丰富的功能（该比值是对易用性的一种测量，由简单和复杂应用共同验证（。
- 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。
- 对于非常大型的项目，将体系结构方面的工作与具体实现向分离是获得概念完整性的强有力方法。
- 如果要得到系统概念上的完整性，就必须有人控制这些概念，这实际上是一种无需任何歉意的贵族专制统治。
- 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。
- 概念上统一的系统能更快地开发和测试。
- 体系结构，设计实现，物理实现的许多工作可以并发进行。
第五章 画蛇添足
- 尽早交流和持续沟通能够是结构师有较好的成本意识，使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
- 结构师如何成功地影响实现：
- 牢记是开发人员承担创造性的实现责任，结构师只能提出建议。
- 时刻准备着为所制定的说明建议一种实现的方法，准备接受任何其他可行的方法
- 对上上述建议保持低调和平静
- 准备对所建议的改进放弃坚持
- 听取开发人员在体系结构桑改进的建议
- 第二个系统时人们所设计的最危险的系统，通常的倾向是过分地进行设计。
- 【不懂】OS/360是典型的画蛇添足的例子
- 为功能分配一个字节和微秒的优先权是一个很有价值的规范化方法
贯彻执行
- 即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。
- 必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。
- 处于精确性的考虑，我们需要形式化地设计定义：同样我们需要记叙性定义来加深理解。
- 必须采用形式化定义和记叙性定义中的一种作为标准，另一种作为辅助措施；它们都可以作为表达的标准。
- 设计实现，包括模仿仿真，可以充当一种体系结构的定义；这些方法有一些严重的缺点。
- 直接整合是一种强制推行软件的结构性标准的方法。
- 【】如果起初至少有两种以上的实现，体系结构定义会更加整洁和规范。
- 允许体系结构师对实现人员的询问做出电话应答解释是非常重要的，而且必须进行日志记录和整理发布（电子邮件是可选的介质）
- 项目经理最好的朋友就是他每天要面对的对手——独立的产品测控机构/小组。
为什么巴比伦塔会失败
- 缺乏交流以及交流的结果——组织的交流
- 因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现，由于对其他人的各种假设，团队成员之间的理解开始出现偏差。
- 团队应该以尽可能多的方式进行相互之间的交流，非正式地进行简要技术陈述的常规项目会议，共享的正式项目工作手册（以及通过电子邮件）。
- 项目工作手册“不是独立的一篇文档，它是对项目必须产生的一系列文档进行组织的一种结构。
- 项目所有的文档都必须是该（工作手册）结构的一部分。
- 需要尽早和仔细设计工作手册结构。
- 实现制定了良好的工作手册，可以将后来书写的文字放置在合适的章节中，并且可以提高产品手册的质量。
- 每一个团队成员应该了解所有的材料（工作手册），即所有团队中的人都应该能够看到所有材料，网页即可满足。
- 实时更新是至关重要的。
- 工作手册的使用者应该将注意力集中在上次阅读后的变更以及关于这些变更重要性的评述上。
- OS/360项目工作手册刚开始使用的是纸，后来换成了微缩胶片。
- 任然需要用变更条和修订日期来标记文字，任然需要后进先出的电子化变更小结。
- 使每个人看到每件事的目标是完全错误的；各个部分应该被封装，从而没有人需要或者被允许看到其他部分的内部结构，只需要了解接口。
- 组织架构
- 团队组织的目标是为了减少必要的交流和协作量
- 为了减少交流，组织机构包括了人力划分和限定职责范围
- 传统的树状组织结构反映了权力的结构原理——不允许双重领导
- 组织中的交流是网状，而不是树状结构，因此所有的特殊组织机制都是为了进行调整，以克服树状组织结构中交流缺乏的困难。
- 每个子项目具有两个领导角色——产品负责人，技术主管或结构师。这两个角色的职能有很大的区别
- 两种角色的任意组合都可以是非常有效的
- 产品负责人和技术主管是同一个人
- 产品负责人作为总指挥，技术主管充当其左右手
- 技术主管作为总指挥，产品负责人充当其左右手
胸有成竹
- 仅仅通过对编码部分时间的估计，然后