《人月神话》拆书
2021-10-11 22:37:43 0 举报AI智能生成
40年经典巨著，软件工程经典书籍《人月神话》
作者其他创作
大纲/内容
第10章 提纲挈领
为什么要有正式的文档
书面记录决策是有必要的
文档能够作为同其他人的沟通渠道
文档可作为数据基础和检查列表
项目经理的任务是制定计划，并实现计划。但是只有书面计划是精确的和可以沟通的
第11章 未雨绸缪
唯一不变的是变化本身
事情在最初总是最好的
为变更设计系统
为变更计划组织架构
第12章 干将莫邪
项目经理应该制定一套策咯，并为通用工具的开发分配资源：与此同时，他还必须意识到专业工具的需求。
同时还需要配备调试机器或者软件，以便在调试过程中，所有类型的程序参数可以被自动计数和测量。
同天文工作者一样，大部分系统调试工作总是在夜间完成。
拋开理论不谈，一次分配给某个小组的连续的目标时间块被证明是最好的安排方法，比不同小组的穿插使用更为有效
第13章 整体部分
好的自上而下的设计从几个方面避免了 bug
清晰的结构和表达方式更容易对需求和模块功能进行精确地描述
模块分割和模块独立性避免了系统级的 bug
细节的抑制使结构上的缺陷更加容易识别
设计在每个精化步骤上都是可以测试的
重视单元测试、系统集成测试
搭建充分的测试平台
第14章 祸起萧墙
里程碑的选择只有一个原则：里程碑必须是具体的，特定的，可度量的时间，能够进行清晰定义
暴露问题的两种方式
减少角色冲突，鼓励共享。通俗点就是不要越俎代庖
建立评审机制，让问题充分暴露
第15章 另外一面
高估了流程图的作用？？40年前作者主要是做的系统软件，但现在面向业务的应用软件，流程图还是很重要的
子文档化的程序。40年前就提出这个，的确是非常伟大的思想
第16-17章 没有银弹
软件开发建议
仔细地进行市场调研，避免开发已上市的产品；
在获取和制定软件需求时，将快速原型开发作为迭代计划的部分；
有机地更新软件，随着系统的运行、使用和测试，逐渐添加越来越多的功能；
不断挑选和培养杰出新生代的概念设计人员。
软件开发总是苦难的，天生就没有银弹
复杂度：不仅仅导致技术产生困难，还引发了很多管理上的问题
一致性：很多复杂性来自保持与其他接口的一致性，对软件的任何再设计，都无法简化这些复杂特性。
可变性：成功的软件都会发生变更
不可见性：软件的客观存在不具有空间的形体特征
Parnas 写道：重用是一件说起来容易，做起来难的事情。它同时需要良好的设计和卓越的文档。即使我们看到了非常罕见的优秀设计，但如果没有好的文档，我们也不会看到能重用的构件。
20年后的《人月神话》
没有构建舍弃原型--瀑布模型是错误的
增量开发模型更佳--渐进地精化
人就是一切
第1章 焦油坑
编程产品 | 编程系统产品
编程的乐趣
创建事物纯粹的快乐
开发对他人有用的东西
过程体现的强大魅力
持续学习的快乐
编程的苦恼
追求完美
由他人设定目标、供给资源和提供信息
寻找琐碎的bug
没有登场可能就已散场
第2章 人月神话
导致项目缺乏合理的进度安排的原因
对估算技术缺乏有效的研究
进度和工作量相互混淆
对估算缺乏信心，导致不做精细估算
对进度缺少跟踪和监督
进度偏移时，只有考虑增加人力
用人月为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人的数量和时间是可以相互替换的。
Books法则：进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later.)
第3章 外科手术团队
团队中一个两倍差距的程序员其生产率有可能相差10倍，这也是为什么优秀的公司总是花高薪请优秀人的原因，并非人傻钱多
像外科手术一样来分解工作和划分团队职能
第4章 贵族专治、民主政治和系统设计
概念的完整性要求设计必领由一个人，或者非常少数互有默契的人员来实现。
第5章 画蛇添足
第二个系统是设计师们设计的最危险的系统
第一个系统比较谨慎，容易控制边界
第三个系统之后，经过前期的验证，可以做通用性的抽象设计，并吸取前两个系统的经验教训
第6章 贯彻执行
标准要统一：不要带两个时钟出海，要么带一个，要么带3个
测试的重要性：项目经理最好的朋友就是每天面对的独立的测试小组
第7章 为什么巴比伦塔会失败
巴比伦塔失败的原因
缺少交流
缺少组织
交流的方式
非正式途径
会议
工作手册
组织架构
产品负责人和技术主管是同一人
适合小团队
大项目不行
既懂技术，又精通管理的人很少
精力顾不过来
产品负责人作为总指挥，技术主管充当左右手
这种方式有些困难，很难建立技术决策上的权威
产品责任人必须对技术主管的技术才能表现尊重
技术主管作为总指挥，产品负责人充当左右手
第8章 胸有成竹
工作量=常数 x 指令的数量的1.5次方
编程只占所有问题的1/6
掌握自己团队生产率的标准
第9章 削足适履
对项目经理而言，必须研究用户及用户需求，以设置待开发系统的规模
空间和时间的平衡，现在我们在架构上经常用空间换时间，因为硬件存储的成本在降低，但40年前不一样
0 条评论
下一页
为你推荐
查看更多
