发表于2024-12-27
正版 人月神话 40周年中文纪念版布鲁克斯Frederick P.Brooks Jr.软 pdf epub mobi txt 电子书 下载
"图灵奖得主、“IBM 360系统之父”作者Brooks颠覆了项目管理领域,长久不衰传奇经典!
软件开发人员、软件项目经理、系统分析师等IT从业者必藏之软工[]!
畅销[]40年!新版再发行
[]软工领域*畅销的项目管理经典!
影响人力编程思想的*牛著作之一!
[]阅读:
第1章 焦油坑
编程系统产品
职业的乐趣
职业的苦恼
第2章 人月神话
乐观主义
人月
系统测试
空泛的估算
重复产生的进度灾难
第3章 外科手术队伍
问题
Mills的建议
如何运作
团队的扩建
第4章 贵族专制、民主[]和系统设计
概念的完整性
获得概念的完整性
贵族专制统治和民主[]
在等待时,实现人员应该做什么
第5章 画蛇添足
结构师的交互准则和机制
自律―― 开发第二个系统所带来的后果
第6章 贯彻执行
文档化的规格说明―― 手册
形式化定义
直接整合
会议和大会
多重实现
电话日志
产品测试
第7章 为什么巴比伦塔会失败
巴比伦塔的管理教训
大型编程项目中的交流
项目工作手册
大型编程项目的组织架构
第8章 胸有成竹
Portman的数据
Aron的数据
Harr的数据
OS/360的数据
Corbató的数据
第9章 削足适履
作为成本的程序空间
规模控制
空间技能
数据的表现形式是编程的根本
第10章 提纲挈领
计算机产品的文档
大学科系的文档
软件项目的文档
为什么要有正式的文档
第11章 未雨绸缪
试验性工厂和增大规模
[]不变的[]是变化本身
为变更设计系统
为变更计划组织架构
前进两步,后退一步
前进一步,后退一步
第12章 干将莫邪
目标机器
辅助机器和数据服务
[]语言和交互式编程
第13章 整体[]分
剔除bug的设计
构件单元调试
系统集成调试
第14章 祸起萧墙
里程碑还是沉重的负担
“其他的[]分反正会落后”
地毯的下面
第15章 另外一面
需要什么样的文档
流程图
自文档化的程序
第16章 没有银弹
摘要
介绍
根本困难
以往解决次要困难的一些突破
银弹的希望
针对概念上根本问题的颇具前途的方法
第17章 再论“没有银弹”
人狼和其他恐怖传说
存在着银弹―― []在这里
含糊的表达将会导致误解
Harel的分析
Jones的观点―― []带来生产率
那么,生产率的情形如何
面向对象编程―― 这颗铜质子弹可以吗
重用的情况怎样
学习大量的词汇―― 对软件重用的一个可预见但还没有被预言的问题
子弹的本质―― 形势没有发生改变
第18章 《人月神话》的观点:是与非
第1章 焦油坑
第2章 人月神话
第3章 外科手术队伍
第4章 贵族专制、民主[]和系统设计
第5章 画蛇添足
第6章 贯彻执行
第7章 为什么巴比伦塔会失败
第8章 胸有成竹
第9章 削足适履
第10章 提纲挈领
第11章 未雨绸缪
第12章 干将莫邪
第13章 整体[]分
第14章 祸起萧墙
第15章 另外一面
第1版结束语
第19章 20年后的《人月神话》
为什么要出版20周年纪念版本
核心观点―― 概念完整性和结构师
开发第二个系统所引起的后果―― 盲目的功能和频率猜测
图形界面的成功
没有构建舍弃原型―― 瀑布模型是错误的
增量开发模型更佳―― 渐进地精化
关于信息隐藏,Parnas是正确的,我是错误的
人月[]有多少神话色彩?Boehm的模型和数据
人[]是一切(或者说,几乎是一切)
放弃权力的力量
[]令人惊讶的新事物是什么?数百万的计算机
全新的软件产业―― 塑料薄膜包装的成品软件
买来开发―― 使用塑料包装的成品软件包作为构件
软件工程的状态和未来
结束语:令人向往、激动人心和充满乐趣的50年
注解与参考文献
附录:人月落地实战体验
一、名家谈人月
1. 年金
2. 《人月神话》与实践
3. Frank Chance评人月
4. 软件尚方宝剑(Silver Bullet)何在
二、名著评人月
三、读者感言
1. 读书有感――人月神话
2. 我这几天很烦(产品概念完整性)
3. 关于我们的思考――“项目开发”及读《人月神话》有感
4. 我的“人月神话”
5. 《人月神话》软玉生香
史前史中,没有别的场景比巨兽们在焦油坑中垂死挣扎的场面更令人震撼。[]见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越猛烈,焦油纠缠得[]越紧,没有哪种猛兽足够强壮或具有足够的技巧,能够挣脱束缚,它们[]后都沉到了坑底。 过去几十年的大型系统开发[]犹如这样一个焦油坑,很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统――不过只有极少数的项目满足了目标、进度和预算的要求。各种团队,大型的或小型的,庞杂的或精干的,一个接一个地淹没在了焦油坑中。表面上看起来好像没有任何一个单[]的问题会导致困难,每个问题都能获得解决,但是当它们相互纠缠和累积在一起的时候,团队的行动[]会变得越来越慢。对于问题的麻烦程度,每个人似乎都会感到惊讶,并且很难看清问题的本质。不过,如果我们想解决问题,[]必须试图先去了解问题。 因此,[]先让我们来认识一下系统开发这个职业,以及充满在这个职业中的乐趣和苦恼吧! 编程系统产品 报纸上经常会出现这样的新闻,讲述两个程序员如何在经过改造的简陋车库中,编出超过大型团队工作量的重要程序。接着,每个编程人员准备相信这样的神话,因为他知道自己能以超过产业化团队的1 000代码行/年的生产率来开发任何程序。 为什么不是所有的产业化队伍都会被这种专注的二人组合所替代?我们必须看一下产出的是什么。 图1-1的左上[]分是程序(Program)。它本身是完整的,可以由作者在所开发的系统平台上运行。它通常是车库中产出的产品,以及作为单个程序员生产率的评估标准。 图1-1 编程系统产品的演进 有两种途径可以使程序转变成更有用但是成本更高的产物,这两种途径表现为图中的边界。 水平边界以下,程序转变成编程产品(ProgrammingProduct)。这是可以被任何人运行、测试、修复和扩展的程序。它可以在多种[]作系统平台上运行,供多套数据使用。要成为通用的编程产品,程序必须按照普遍认可的风格来编写,特别是输入的范围和形式必须广泛地适用于所有可以合理使用的基本算法。接着,对程序进行彻底测试,确保它的稳定性和可靠性,使其值得信赖。这[]意味着必须准备、运行和记录详尽的测试用例库,用来检查输入的边界和范围。此外,要将程序提升为程序产品,还需要有完备的文档,每个人都可以加以使用、修复和扩展。经验数据表明,相同功能的编程产品的成本,至少是已调试的程序的成本的3倍。
史前史中,没有别的场景比巨兽们在焦油坑中垂死挣扎的场面更令人震撼。[]见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越猛烈,焦油纠缠得[]越紧,没有哪种猛兽足够强壮或具有足够的技巧,能够挣脱束缚,它们[]后都沉到了坑底。
过去几十年的大型系统开发[]犹如这样一个焦油坑,很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统――不过只有极少数的项目满足了目标、进度和预算的要求。各种团队,大型的或小型的,庞杂的或精干的,一个接一个地淹没在了焦油坑中。表面上看起来好像没有任何一个单[]的问题会导致困难,每个问题都能获得解决,但是当它们相互纠缠和累积在一起的时候,团队的行动[]会变得越来越慢。对于问题的麻烦程度,每个人似乎都会感到惊讶,并且很难看清问题的本质。不过,如果我们想解决问题,[]必须试图先去了解问题。
因此,[]先让我们来认识一下系统开发这个职业,以及充满在这个职业中的乐趣和苦恼吧!
编程系统产品
报纸上经常会出现这样的新闻,讲述两个程序员如何在经过改造的简陋车库中,编出超过大型团队工作量的重要程序。接着,每个编程人员准备相信这样的神话,因为他知道自己能以超过产业化团队的1 000代码行/年的生产率来开发任何程序。
为什么不是所有的产业化队伍都会被这种专注的二人组合所替代?我们必须看一下产出的是什么。
图1-1的左上[]分是程序(Program)。它本身是完整的,可以由作者在所开发的系统平台上运行。它通常是车库中产出的产品,以及作为单个程序员生产率的评估标准。
图1-1 编程系统产品的演进
有两种途径可以使程序转变成更有用但是成本更高的产物,这两种途径表现为图中的边界。
水平边界以下,程序转变成编程产品(Programming Product)。这是可以被任何人运行、测试、修复和扩展的程序。它可以在多种[]作系统平台上运行,供多套数据使用。要成为通用的编程产品,程序必须按照普遍认可的风格来编写,特别是输入的范围和形式必须广泛地适用于所有可以合理使用的基本算法。接着,对程序进行彻底测试,确保它的稳定性和可靠性,使其值得信赖。这[]意味着必须准备、运行和记录详尽的测试用例库,用来检查输入的边界和范围。此外,要将程序提升为程序产品,还需要有完备的文档,每个人都可以加以使用、修复和扩展。经验数据表明,相同功能的编程产品的成本,至少是已调试的程序的成本的3倍。
回到图中,垂直边界的右边,程序转变成编程系统(Programming System)中的一个构件单元。它是在功能上能相互协作、具有规范的格式、可以进行交互的程序集合,并可以用来组装和搭建整个系统。要成为编程系统构件,程序必须按照一定的要求编制,使输入和输出在语法和语义上与精确定义的接口一致。同时程序还要符合预先定义的资源限制―― 内存空间、输入输出设备、计算机时间。[]后,程序必须同其他系统构件单元一道,以任何能想象到的组合进行测试。由于测试用例会随着组合不断增加,所以测试的范围必须广泛。因为一些意想不到的交互会产生许多不易察觉的bug,测试工作将会非常耗时,因此相同功能的编程系统构件的成本至少是[]立程序的3倍。如果系统有大量的组成单元,成本还会更高。
图1-1的右下[]分代表编程系统产品(Programming Syst[] Product)。与以上的所有的简单的程序都不同的是,它的成本高达9倍。然而,只有它才是真正有用的产品,是大多数系统开发的目标。
职业的乐趣
编程为什么有趣?作为回报,它的从业者期望得到什么样的快乐?
[]先,这种快乐是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到快乐一样,成年人喜欢创建事物,特别是自己进行设计。我想这种快乐是[]创造世界的[]射,一种呈现在每片[]特的、崭新的树叶和雪花上的喜悦。
其次,这种快乐来自于开发对他人有用的东西。内心深处,我们期望我们的劳动成果能够被他人使用,并能对他们有所帮助。从这一角度而言,这同小孩用粘土为“爸爸的办公室”捏制铅笔盒没有任何本质的区别。
第三,快乐来自于整个过程体现出的一股强大的魅力―― 将相互啮合的零[]件组装在一起,看到它们以精妙的方式运行着,并收到了预期的效果。比起弹球游戏机或自动电唱机所具有的迷人魅力,程序化的计算机毫不逊色。
第四,这种快乐是持续学习的快乐,它来自于这项工作的非重复特性。人们所面临的问题总有这样那样的不同,因而解决问题的人可以从中学习新的事物,有时是实践上的,有时是理论上的,或者兼而有之。
[]后,这种快乐还来自于在易于驾驭的介质上工作。程序员,[]像诗人一样,几乎仅仅在单纯的思考中工作。程序员凭空地运用自己的想象,来建造自己的“城堡”。很少有创造介质如此灵活,如此易于精炼和重建,如此容易实现概念上的设想(不过我们将会看到,容易驾驭的特性也有它自己的问题)。
然而程序毕竟同诗歌不同,它是实实在在的东西;它可以移动和运行,能[]立产生可见的输出;它能打印结果,绘制图形,发出声音,移动支架。神话和传说中的魔术在我们的时代已变成现实。在键盘上键入正确的咒语,屏幕会活动、变幻,的也不可能存在的事物。
编程的快乐在于它不仅满足了我们内心深处进行创造的渴望,而且还唤醒了每个人内心的情感。< 正版 人月神话 40周年中文纪念版布鲁克斯Frederick P.Brooks Jr.软 电子书 下载 mobi epub pdf txt
正版 人月神话 40周年中文纪念版布鲁克斯Frederick P.Brooks Jr.软 pdf epub mobi txt 电子书 下载