《人月神话》读书笔记⑤：总结与更新

十七、根本与次要问题：再论“没有银弹”"No Silver Bullett"Refired

·创造性活动包括：概念性结构的形式规格化、使用现实的介质来实现、在实际使用中与用户交互

·如果开发的次要部分少于整个工作的9/10，几十不占用任何时间，也不会给生产率带来数量级的提高。

·复杂性是层次化的，通过分层的模块或对象

·软件系统增加必要的复杂性，增量化，可使系统持续地运行。

·质量带来生产率，很多代价高昂的后续项目投入了大量的时间和精力来寻找和修复规格说明、设计和实现上的错误。

·系统化软件开发方法的发展是未来解决质量问题（特别是避免大型灾难），而不是出于生产率方面的考虑

·成品软件这个大众市场是软件工程领域中，意义最深远的开发方向，购买、而非开发

·面向对象编程特征：强制的模块化和清晰的接口；强调封装；强调继承和伴随着的层次化类结构及虚函数；强调强抽象数据类型化

·代码重复使用的问题：现阶段零部件的库是无法满足的，需要复合产品让人去学习代码的意义

十八、《人月神话》的观点：是与非Propositions of The Mythical Man-Month;True or False

·本章是再版时，对前面17章的一个总结，现摘录如下

第一章：编程系统产品内高成本的构件在根本上是相互独立的；编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有情感”

第二章：缺乏合理时间进度是造成项目滞后的最主要原因；所有编程人员都容易过于乐观；围绕成本核算的估计技术，混淆了工作量和项目进度；时间安排，1/3计划、1/6编码、1/4构件测试，1/4系统测试；为进度落后的项目增加人手，只会使项目更加落后

第三章：经验和实际表现之间没有相互联系；由少数头脑产生的产品完整性，再由多位协助人员达到总体生产率，减少沟通的工作量

第四章：概念完整性是系统设计中最重要的考虑因素；体系结构、设计实现、物理实现的许多工作可以并行

第五章：尽早交流和持续沟通能使结构师有较好的成本意识；牢记是开发人员承担创造性的实现工作，结构师只能提出建议

第六章：形式化地设计定义，记叙性地理解定义；大型团队，也必须只能由一个或两个人来完成设计结果

第七章：缺乏交流是恐怖的；但是每个人看到每件事的目标是完全错误的，每个部分应该被封装，大家只需要看到接口即可

第八章：仅仅通过代码部分时间的估计，然后乘以其他部分的相对系数，是无法得出对整项工作的精确估计的；使用适当的高级语言

第九章：开发人员必须控制规模；系统结构师必须保持持续警觉，确保连贯的系统完整性

第十章：不管大小项目，都应该对文档进行规范化处理

第十一章：做好系统的丢弃和重新设计的准备；开发人员交付的是用户满意程度，而不仅仅是实际的产品；程序维护就是前进两步、后退一步的过程

第十二章：一次分配给一个小组的连续目标时间块是最好的安排方法；编程中，节省最大工作量的工具可能是文本编辑系统

第十三章：规格说明必须提交给外部测试小组，以仔细检查说明的完整性和明确性；自上而下地进行设计（逐步细化）是最重要的新型形式化软件开发方法

第十四章：一天一天的进度落后比起重大灾难更难识别；进度表里的里程碑必须是具体的、特定的和可度量的事件；必须有人对里程碑进行维护和控制；老板不要越俎代庖

第十五章：描述性文字在程序里是必要的；文档中整个生命周期对克服懒惰和进度的压力起促进和激励作用；测试用例包括校验输入数据、边界输入数据、无效的输入数据

·总结：软件系统可能是人类创造中最复杂的十五

·软件工程的焦油坑将在未来很长一段时间内使人举步维艰

---

以上内容为《人月神话》（作者：[美]小弗雷德里克·布鲁克斯）的第17-18章读书笔记及部分摘要，本人加入一定量自己的理解；因水平有限，欢迎大家交流指正，谢谢~

另：《人月神话》是比较偏技术侧的书籍，翻译过来有点佶屈聱牙，我这里更多只是列了提纲，大家有机会自己去看、可以有更多收获~