读软件工程经典《人月神话》观点摘抄和我的理解之二

 

同上一篇观点摘抄（部分）

 

Brooks的观点拿到现在，不一定都是金科玉律，但是我们得分析，哪些还是客观规律，必须遵循；哪些需要与时俱进；我们应当对Brooks的观点有所增益。

 

第4章 贵族专制、民主政治和系统设计 

4.1 “概念完整性是系统设计中最重要的考虑因素”。 

      我的理解：概念完整性是系统的一个最重要的问题，但是好像在身边做开发这个领域，对此予以充分关注的很少。

4.2 “功能与理解上的复杂程度的比值才是系统设计的最终测试标准”，而不仅仅是丰富的功能。[该比值是对易用性的一种测量，由简单和复杂应用共同验证。] 

      我的理解：在需求和设计时，设计复杂度、实现复杂度、运维复杂度、学习成本和使用复杂度是必须要考虑的，最好能在文档中体现和确认。

 

4.3 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。 

 

      我的理解：参见一种反模式：委员会设计（Design by committee）：很多人同时进行设计，却没有统一的看法。即便相互妥协出一致的看法，也是大锅菜杂烩。

 

4.4 “对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。”[同样适用于小型项目。] 

       我的理解：可惜现在能这么做的很少，领导对这个有充分理解的更是少之又少。

 

4.5 “如果要得到系统概念上的完整性，那么必须控制这些概念。这实际上是一种无需任何歉意的贵族专制统治。” 

     我的理解：大家都参与的设计方式与资深人员专制设计，让我联想到政治。

 

4.6 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。 

4.7 概念上统一的系统能更快地开发和测试。 

     我的理解：在需求和设计时明确“概念”这一核心是一种正本清源的方法。

   

第5章 画蛇添足

5.2 结构师如何成功地影响实现： 

1）牢记是开发人员承担创造性的实现责任；结构师只能提出建议。 

2）时刻准备着为所指定的说明建议一种实现的方法，准备接受任何其他可行的方法。 

3）对上述的建议保持低调和平静。

4）准备对所建议的改进放弃坚持。

5） 听取开发人员在体系结构上改进的建议。

 

     我的理解：这是架构师的工作指南和原则。

 

第7章 为什么巴比伦塔会失败？ 

7.1 巴比伦塔项目的失败是因为缺乏交流，以及交流的结果——组织。

 
7.2 “因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于对其他人的各种假设，团队成员之间的理解开始出现偏差。 

7.16 团队组织的目标是为了减少必要的交流和协作量。

7.20 每个子项目具有两个领导角色——产品负责人、技术主管或结构师。这两个角
色的职能有着很大的区别，需要不同的技能。 

7.21两种角色中的任意组合可以是非常有效的： 

•  产品负责人和技术主管是同一个人。 
•  产品负责人作为总指挥，技术主管充当其左右手。 ?? 技术主管作为总指挥，产品负责人充当其左右手。 

 

第10章 提纲挈领 

10.9 项目经理的基本职责是使每个人都向着相同的方向前进。 

10.10 项目经理的主要日常工作是沟通，而不是做出决定；文档使各项计划和决策在整个团队范围内得到交流。

      我的理解：项目经理们，你们在做什么？

第11章 未雨绸缪 

11.3 对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之。 

11.8 用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。

 

11.9 软件产品易于掌握的特性和不可见性，导致了它的构建人员（特别容易）面临着永恒的需求变更。 

 

       我的理解：面临需求变更，要理性，要平静。

 

11.10 目标上（和开发策略上）的一些正常变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。 

     我的理解：未雨绸缪适度即可，无需考虑太过。

11.14 程序员不愿意为设计书写文档的原因，不仅仅是由于惰性。更多的是源于设计人员的踌躇——要为自己尝试性的设计决策进行辩解。

 

    我的理解：请大家理解程序员的工作，不要过多的指责，他们多数也是想把工作完成得更好。

 

11.15 为变更组建团队比为变更进行设计更加困难。

 

   我的理解：大实话，可惜领导们一般不这么看。

 

11.16 只要管理人员和技术人才的天赋允许，老板必须对他们的能力培养给予极大的关注，使管理人员和技术人才具有互换性；特别是希望能在技术和管理角色之间自由地分配人手的时候。 

11.17 具有两条晋升线的高效组织机构，存在着一些社会性的障碍，人们必须警惕和积极地同它做持续的斗争。 

11.18 很容易为不同的晋升线建立相互一致的薪水级别，但要同等威信的建立需要一些强烈的心理措施：相同的办公室、一样的支持和技术调动的优先补偿。 

11.19 组建外科手术队伍式的软件开发团队是对上述问题所有方面的彻底冲击。对于灵活组织架构问题，这的确是一个长期行之有效的解决方案。

11.20 程序维护基本上不同于硬件的维护；它主要由各种变更组成，如修复设计缺陷、新增功能、或者是使用环境或者配置变换引起的调整。 

11.21 对于一个广泛使用的程序，其维护总成本通常是开发成本的40％或更多。 11.22 维护成本受用户数目的严重影响。用户越多，所发现的错误也越多。

11.27 设计实现的人员越少、接口越少，产生的错误也就越少。

 

11.29 所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。即使是最熟练的软件维护工作，也只是放缓了系统退化到不可修复混乱的进程，从中必须要重新进行设计。[许多程序升级的真正需要，如性能等，尤其会冲击它的内部结构边界。原有边界引发的不足常常在日后才会出现。] 

 

第13章 整体部分 

13.2 V.A.Vyssotsky提出，“许许多多的失败完全源于那些产品未精确定义的地方。” 

 

       我的理解：说清楚了，做出了即便有困难也不会太大；但是说不清楚，就很难设计实现，即便设计实现出来也是失败和错误。

13.3 在编写任何代码之前，规格说明必须提交给测试小组，以详细地检查说明的完整性和明确性。开发人员自己不会完成这项工作。（Vyssotsky） 

    我的理解：现在一般都这么做了，但是很多时候是形式起不到实际作用。

第14章 祸起萧墙 

14.1 “项目是怎样延迟了整整一年的时间？…一次一天。” 

14.2 一天一天的进度落后比起重大灾难，更难以识别、更不容易防范和更加难以弥补。 

14.4 里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。