《人月神话》读书笔记

目录

内容概括

焦油坑

人月神话

外科手术队伍

贵族专制、民主政治和系统设计

画蛇添足

贯彻执行

为什么巴比伦塔会失败?

胸有成竹

削足适履

提纲挈领

未雨绸缪

干将莫邪

整体部分

祸起萧墙

另外一面

没有银弹-软件工程中的根本和次要问题

再论《没有银弹》

《人月神话》的观点:是或非?

20年后的人月神话

读后感


写在前面:本读书笔记以《人月神话》二十周年版为蓝本,其中翻译与40周年版有些许差别。内容概括中部分语句摘录自《人月神话》原文。

内容概括

焦油坑

大型系统开发宛如史前时代的焦油坑吞没成千上万的巨兽般吞没了各种各样的开发团队。编程是一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。我们从中获得创造事物的纯粹快感,用魔术般的力量开发出切实有益的产品。然而,在现有时间和有效资源之间,寻找解决实际问题的切实可行方案,实现完美调度,又常常使人头痛不已。

人月神话

在众多软件项目中,缺乏合理的时间进度是造成项目滞后的最主要原因。在估计和进度安排中常以人月作为工作量单位,它暗示着人员数量和时间是可以相互替换的,而这样的互换在系统编程中近乎不可能。向进度落后的项目中增加人手,只会使进度更加落后。对于软件任务的进度安排,编码仅仅分配六分之一的时间,我们需要给系统测试以充分的时间。

外科手术队伍

对于大型系统,我们既要保证效率和概念的完整性,又要使产品能满足时间要求。Mills 建议大型项目的每一个部分由一个团队解决,但是该队伍以类似外科手术的方式组建,充分实现团队成员的专业化合理化分工。

贵族专制、民主政治和系统设计

在系统设计中,概念完整性应该是最重要的考虑因素。对于非常大型的项目,将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。从某种意义上说,系统开发是结构师的贵族专制统治。

画蛇添足

在开发第一个系统时,结构师倾向于精炼和简洁。第二个系统是设计师们所设计的最危险的系统。一种普遍倾向是过分地设计第二个系统,向系统添加很多修饰功能和想法,它们曾在第一个系统中被小心谨慎地推迟了。避免画蛇添足,需要立足实际、贯彻理念、谨慎变更、加强交流。

贯彻执行

保证系统概念上的完整性,我们需要文档化的规格说明,并保证其清晰、完整和准确。手册的作者必须注意自己的思路和语言,达到所需要的精确程度,对文档定义使用形式化标记方法。还需善以各种会议形式、电话日志等加强沟通。另外,独立测试小组是保证质量、贯彻决策的必要手段。

为什么巴比伦塔会失败?

在大型编程项目中,高效即时的交流是质量进度的重要保障。可以通过会议、工作手册或其他非正式途径加强交流。工作手册不仅要做到规格清晰,还要做到实时更新。在组织架构上,要做到合理明确,参考外科手术团队。

胸有成竹

对项目花费时间和工作量的估算不能仅仅局限于编码,计划、编制文档、测试、系统集成和培训的时间必须被考虑在内。生产率会根据任务本身复杂度和困难程度表现出显著差异。对项目进度的合理估算可以让项目的实施有如成竹在胸。

削足适履

对项目经理而言,规模控制既是技术工作的一部分,也是管理工作的一部分。在规模控制中,仅对核心程序设定规模目标是不够的,必须把所有的方面都编入预算;在指明模块有多大的同时,确切定义模块的功能;培养开发人员从系统整体出发、面向用户的态度。合理规划空间、时间和功能。巧妙的算法有助于实现更高质量的程序。

提纲挈领

文档在项目开发中有举足轻重的地位。文档的跟踪维护是项目监督和预警的机制。文档本身可以作为检查列表、状态控制,也可以作为汇报的数据基础。文档的记录风格清晰,也要有所侧重。

未雨绸缪

不变只是愿望,变化才是永恒。新的系统概念或新技术不断出现,开发的系统也必然会存在一个丢弃、重新设计的过程。接受变化的事实,开发人员需要随着学习的过程更改设计,为变更计划系统、组织框架。

干将莫邪

开发和维护通用的编程工具会让项目开发的效率更高。项目经理需要合理地为通用工具的开发分配资源。项目经理必须考虑、计划、组织的工具首先是计算机设施,然后是实用程序、 调试辅助程序、测试用例生成工具和处理文档的字处理系统。合适的开发工具和高级语言宛如良工利器可以使项目的开发事半功倍。

整体部分

在贯彻概念完整性的同时,我们仍需要对产品有细致的功能定义、规范化的功能描述。根据自顶向下设计理念,程序设计应该是一系列的精化设计,要保证模块的准确分割和其独立性,对各模块的需求和功能有精确的描述。测试可以尽早分层开始,必须使用全面而科学的方法。

祸起萧墙

项目迟滞往往是累积产生的。可以通过制定进度表,设立里程碑来对项目进度进行准确地监控。里程碑必须是具体的、特定的、可度量的事件,能够进行清晰定义。在软件开发团队,进取心里同样非常必要。可以通过PERT技术来考量每一次地偏离,调控进度。

另外一面

优秀的文档会对用户接受和使用产品产生极大影响。文档要具有针对性,对程序进行有效的描述。流程图也不失为一种好的办法。可以通过“合并文档”,即把文档整合到源代码的方式,保证程序文档质量和维护力度。

没有银弹-软件工程中的根本和次要问题

没有任何技术或管理上的进展,能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。软件开发中困难的部分是规格化、设计和测试这些概念上的结构,而不是对概念进行表达和对实现逼真程度进行验证。软件的各种特性(复杂性、一致性、可变性、不可见行)暗示,一劳永逸解决软件危机的银弹根本不存在。作为潜在银弹的最先进的技术进步也并没有解决软件领域的根本问题。

再论《没有银弹》

时过境迁,《没有银弹》引发的热议仍在延续。人们对《没有银弹》疑问中的一些观点表达异议纷纷。即便新技术层出不穷,软件生产率得到大幅度提升,彻底解决软件危机的银弹还是难以到来。

《人月神话》的观点:是或非?

本章为作者对各章节的观点做的总结。

20年后的人月神话

《人月神话》已出版多年,尽管其中的观点早已为软件从业人员耳熟能详,但其中的理念仍对当今的软件开发实践活动具有指导意义。而正如第一章的描述,软件工程的焦油坑在将来很长一段时间内会继续地使人们举步维艰,无法自拔。这个复杂的行业需要:进行持续的发展;学习使用更大的要来开发;新工具的最佳使用;经论证的管理方法的最佳应用;良好判断的自由发挥;以及能够使我们认识到自己不足和容易犯错的——上帝所赐予的谦卑。

读后感

《人月神话》作为软件工程的经典著作,曾被坊间誉为程序员的圣经,但实际上,它并不是教人如何去做好一个程序员,而是探讨了项目经理或者系统架构师的工作。书中大量举证了作者开发操作系统 OS/360时的项目经验,其间观点和论断大多已经成为当今软件开发的常识。

布鲁克斯无疑是从一个较为宏观的角度看待软件开发的过程,以其自身开发经典大型项目的经历为基础,结合软件工程发展历史,描绘了软件项目开发和管理的蓝图。这样的蓝图,即便未曾从事过软件开发工作,在阅读完本书之后,都能了然于胸。实际上,对于学生或者初入职场的普通程序员,很难全面接触到如书中描述那般翔实的开发。然而,正如我们看历史剧、纪录片,仰望星空偶尔也探究一下宇宙起源,沐染春华秋实而悉数更迭交替,学习软件工程,我们应该去阅读这本书,它带给我们思考,经典书籍本就容易激发人的思考,它带给我们对于软件行业和从业的思考,它让我们明白从事软件开发,应该拥有怎样的自觉。

软件行业,变化是不断的,剧变是罕见的,目前来看,我们更需要的是技术累积而非技术爆炸。而作为一名软件开发人员,我们需要时刻保持合作竞争的精神。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值