人月神话是一本关于软件设计的思考和经验文章集合，作者是美国布鲁克斯。书籍不仅只是罗列心经，也借助一些文化、神话等故事来结合阐述自己的心得，使得书籍读起来更加有意思。虽然书籍出版距今已有40年，但是很多理念在当下的系统设计中仍然不乏适用，是可值得一读的书籍。
主要抄录和理解梳理如下：
1.人月神话
乐观主义所带来的错误假设：一切都将正常运行，每一项任务仅花费它所“应该”花费的时间；用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话
这种场景仅适用如下情况：任务可以彻底分解，他们之间不需要交流
建议可以分配的时间安排：1/3计划>1/6编码>1/4构件>1/4系统测试
人月工时.png
2.外科手术队伍
效率高和效率低的实施者之间个体差异非常大，经常能够达到数量级的水平
大型团队的沟通和处理任务很复杂，Mills的建议方案：一个人去分解任务，并分配给其他人工作，类似外科手术的工作
3. 贵族专制、民主政治和系统设计
概念的完整性：减少花费在学习、时间、记忆和搜索的时间，易用性就会提高，因此概念完整性是系统设计中的重要考虑因素
为了维护系统的概念完整性，需要有统一术语和概念或者规范，这类似贵族专制统治
多数人的协作方式：1.对设计方法和具体实现做分工，2.一个人做分工
在等待时，实现人员应该做什么：体系结构、设计实现、物理实现：往往可以并行进行
4.画蛇添足
最原始的系统一般都会很简洁，第二个系统往往会是危险的系统，通常会基于第一个系统做过多过分设计
5.贯彻执行
即使是大型的设计团队，设计结果必须由一个人或两个人来完成，保证决定的结果是一致的
如果在定义体系中与原先定义不同的地方，重新定义详细程度非常有必要，并且要达到可表达的标准
允许体系设计人员对实现人员的疑惑做解释，并做日志记录和整理发布，防止出现实现中出现歧义
6.巴比伦塔的失败
交流的重要性：团队应该尽可能多的方式进行交流，非正式和正式的交流可以共享进度
工作手册：需要尽早设计工作手册结构，共享工作手册，这是项目的工作产出结果，每个团队成员应该能够看到所有材料，而非需要打印纸张
组织架构：组织的设计是尽量减少必要的交流和协作；网状的协作方式和树状的权力结构设计是不一样的，每个项目有两个领导角色-产品负责人和技术主管
7 胸有成竹
仅通过部分编码时间的估计，乘以其他部分的相对系数，是无法得出整项工作的工时
使用适当的高级语言，可以使生产率提高5倍
8.削足适履
除了运行时间外，程序所占用的内存空间也是主要开销，特别对于操作系统
规模预算在功能设计时也需要考虑，在系统的局部不断优化中，为了满足实现成本减少的目标，优化逐渐缺少对用户整体影响的考虑
精炼、充分和快速的程序往往是战略突破的结果，而不仅仅是技巧的提高，这种突破往往是一种新型的算法；更普遍的是，战略的图突破通常来自于对数据或者表的重新表达，数据的表现形式是编程的根本
9. 提纲挈领
项目经理的主要日常工作是沟通，而不是做出决定，项目的文档使得各项计划和决策得以在整个团队范围内得到交流
不管是学校、工程都会有大同小异的关键文档手册，软件项目也是相同的，需要考虑项目目标、用户手册、内部文档、进度、预算、组织架构等手册
再小的小型项目，项目经理应该对项目的文档做规范化
文档的作用：多次会议的细小决定都是每一个工作的注意力和思考的提炼，正是因为这些文档，是的人们可以在乱象中理清思路
10. 未雨绸缪
对于系统设计而言并非一簇而就的，可以考虑一次性完成，也可以一步步分块实现
第一个开发的系统，往往对用户不合用，它可能太慢、太大或者难以使用，分段设计可以减少用户不必要的修改代价，可拓展软件的不可见性
需求变更是在系统上线后不可避免的事情，维护成本需要考虑，所有修改都倾向于破坏系统的架构
11 祸起萧墙
里程碑是必要的，具体的、特定的和可度量的，有明确的定义
一天天进度落后比起重大灾难更难以识别，更不容易规范，更加难以识别
使用PERT图可以方便进度管理，是的人们能够清晰辨别计划偏移的情况
12. 另外一面
程序的文档描述和程序相比，对机器识别来说，都是同等重要的
文档的描述性文字是有必要的，因为用户和作者在漫长的时间后也会存在遗忘
有效编制文档的方式：文档的关键章节、相关测试用例、程序内部结构化的文档都是有必要的
最小化文档的参考建议：记住必要存在的语句，如名称、声明；使用空格和格式表现从属和嵌套关系；使用段落注释方便理解
文档的修改记录中，不仅要描述事情如何，也需要考虑为什么那样，方便加深理解，目的是很关键的
网友评论