《人月神话》拆书
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 条评论
下一页
为你推荐
查看更多