标签：
人月神话读后感
1. 焦油坑
编程系统产品的成本数倍于编程本身；编程这样一个行业给人以创造、动手与控制的乐趣，但是，对沟通的依赖、对完美的追求也是编程所令人苦恼的一面。
2 人月神话
“一切都将运转良好”在软件工程中是不适用的；完成工作的人数与时间是不能进行简单的互换的，因为沟通需要额外的成本；Brook法则：向进度落后的项目中添加人手，只会使进度更加落后。
3 外科手术队伍
程序员在生产率上甚至可以达到数量级的差异；专业的、分工良好的小规模团队的生产率更高，在这种架构下，决策的集中性也保证了概念的一致性。
4 贵族专制、民主政治和系统设计
概念的完整性最应该被重视，它带来产品的简洁和易懂；因此，系统的体系结构设计应由少数人来完成，即系统设计师专制；但系统设计师应该严守底线，避免干涉外部特征之外的实现细节。
5 画蛇添足
在第一版设计中，设计师往往能保证精炼简洁；但在第二版设计时，画蛇添足是常见的问题，设计师容易被诱惑着开发过多的功能，这是应该被避免的。
6 贯彻执行
对产品的文档化规格说明是必要的，它应该用清楚的形式化定义表达；开发人员之间应该定期有不同层次（大会、组例会、电话）的交流，并对交流进行记录、整理和思考；开发人员应坚守手册，尤其在有多重实现时；大型项目中的测试小组对确保用户体验十分重要。
7 为什么巴别塔会失败
巴别塔有着清晰的目标、充足的人力、材料、技术和时间，但是巴别塔的建造人员缺乏沟通；大型软件工程应有不同层次的沟通，并用项目工作手册规定定义接口与划分以减少交流所需的工作量；软件工程的组织结构应采取树形结构，以保证有效的沟通。
8 胸有成竹
本章将对生产率的估计，工作量 = 常数×指令数目1.5，本章还总结了一些软件工程中一些对生产率进行估计的技术。
9 削足适履
程序空间也是与时间一样的成本，程序规模应该为预算所控制；空间与时间可以进行一定的折中，但好的数据处理方式是可以在两方面同时进行优化的。
10 提纲挈领
软件项目经理应该编写一系列关键的文档，它们反映了对目标、技术特征、进度、预算和组织结构的管理；它们不仅仅是检查列表和控制手段，它也是沟通渠道和汇报材料。
11 未雨绸缪
第一次开发的系统应该准备好要抛弃，因为变化不可避免，要对此计划好系统与组织架构的变化；缺陷修复会引入新的BUG，而且到了最后必然会不能再进行改进。
Chap.12 干将莫邪
工具的安排：软件将最终在之上运行的目标机和开发辅助机，目标机应该被规划使用，辅助机上应该运行可靠的仿真器、解释器和程序库文档。
13 整体部分
概念完整性与产品精确定义是关键的；结构化编程是必要的；构件应该进行单独的测试，之后再进行集成测试；修改时应控制变更规模。
14 祸起萧墙
里程碑应该明确定义以防止产生隐瞒；使用PERT图指示对进取的需要；老板不应与一线经理产生角色冲突，而应使用能了解状态真相的评审机制，计划和控制小组在这一过程中很有价值。
15 另外一面
用户需要文档来帮助他们使用（目的、环境、IO范围、功能算法、指令、选项、运行时间和精度检验）、验证和修改程序；流程图的使用与维护都很麻烦，已经过时；自文档化技术是一种非常有效的解决方案。
16 没有银弹
软件开发所不可规避的困难在于复杂度、一致性、可变性和不可见性；尽管高级语言、分时系统、IDE在编码过程中帮了程序员的大忙，但他们无助于解决内在困难；高级编程语言、面向对象技术、人工智能、专家系统、自动编程、图形化编程和更快的工作站都无助于问题的根本部分；有希望缓解根本问题的是：购买软件、快速原型技术、增量开发和卓越的设计人员
标签：
原文地址：http://www.cnblogs.com/bingoing/p/4307461.html
