书籍作者:小弗雷德里克·P.布鲁克斯 | ISBN:9787302635383 |
书籍语言:简体中文 | 连载状态:全集 |
电子书格式:pdf,txt,epub,mobi,azw3 | 下载次数:9872 |
创建日期:2024-04-09 | 发布日期:2024-04-09 |
运行环境:PC/Windows/Linux/Mac/IOS/iPhone/iPad/Kindle/Android/安卓/平板 |
小弗雷德里克·P.布鲁克斯(Frederick P. Brooks, Jr.1931—2022),图灵奖得主、美国国家科学院院士,对计算机体系结构、操作系统和软件工程做出里程碑式贡献的计算机科学家。
布鲁克斯博士于20世纪60年代初主持与领导了被称为人类从原子能时代进入信息时代的标志的IBM/360系列计算机的开发工作,取得辉煌成功,被认为是“IBM 360系统之父”。布鲁克斯博士创立了北卡罗来纳大学的计算机科学系,并于1965—1985年担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。
布鲁克斯博士作为硬件和软件的双重专家和出色的教育家始终活跃在计算机舞台上,因其专业成就和对计算机体系结构的卓越贡献而屡获表彰,包括美国国家技术奖、ACM杰出服务奖、ACM Fellow、ACM Newell奖、IEEE McDowell奖、计算机先驱奖、冯·诺伊曼奖、富兰克林学会鲍尔奖、图灵奖等。
这是本书中唯一的一节废话。
我是一个书狂,积习甚深,费尽心机在软件工程、系统工程方面收集了一些书。书,在我看来当分为神品、精品和普通三等,其中神品、精品又分别有一、二和三品之分。我所收集的书中,软件工程书大都属于精品,神品只有两本,Frederick P. Brooks的这本书就属于神品之列。
软件作为一个行业,逐步背起了“solving the wrong problem”
(解决错误的问题)的名声。问题决定解决方案,这也就是说,我们一直在制造错误解决方案!这方面有大量的证据,其中最著名的是美国政府统计署(GAO)的数据:全球最大的软件消费商(美国军方)每年要花费数十亿美元购买软件,而在其所购软件中,可直接使用的只占2%,另外3%需要做一些修改,其余95%都成了垃圾。一句话,不管这些软件是否符合需求规格,它们都显然没有满足客户的需求。面向对象技术并没有给我们带来“神奇的效应”,不管开发商如何吹嘘面向对象OO(Object-Oriented)工具多么万能,也不管那些OO狂热者多
[1] *编注:该序的作者是王计斌(Dave Wang),清华大学博士,研究方向包括软件工程和集成产品开发(IPD),长期从事IPD/CMM推行,创办软件工程研究与实践论坛,现在华为技术有限公司工作。
么毅然地前赴后继,这方面的数据从20世纪80年代以来并没有发生大的改观。
这实在令我们的软件工程专家和从业人员们羞愧,因为它揭示了我们可能一开始就从根本上做错了什么!20世纪90年代中期,当软件工程一代宗师Michael Jackson(非歌坛巨星Michael Jackson)宣布他们的研究结果时,立刻在软件工程界激起了阵阵涟漪。Jackson指出,软件从业人员和方法学大师们只是简单地模仿和照搬其他学科的方法,却将最重要的方面(问题域)忽略了。他指出,面向对象方法和结构化方法对问题域的处理没有什么大的区别,却被人们过分地用美好的词汇美化了:
……从众多面向对象建模的描述中,你可以很清楚地看到这些恶果。而且它们还经常伴随着有关现实世界建模的非常美好的词汇。然而,仔细看看,你就会发现它们其实是彻头彻尾的编程对象!如果说有任何和现实世界对象相似的地方,不管是死是活,纯属巧合……
回首软件工程近40年的发展,Jackson哀叹软件行业普遍缺乏专业性,充满了业余人员,“手中有一个锤子,看到什么都是钉子”,谁都可以开发性命攸关的软件。
这就是我们面临的严峻而复杂的现实,也许您会感到震惊!然而在大师Frederick P. Brooks眼里,是那么的平静。因为早在28年前,他就在《人月神话》(The Mythical Man-Month)这本不朽著作中对这些内容做了深入论述。
这本小册子行文优美,思想博大精深,字字真言,精读之有不尽的趣味,藏之又是极珍贵的文献,明眼高人,自能鉴之。
前些年,一位朋友从印度归来,说此书在印度极为普及,我也动起笔来,但惭愧终未成正果。汪颖兄素来勤恳,明知此翻译为“success without applause, diligence without reward”(没有掌声的成功,没有回报的勤勉),却兢兢业业,反复琢磨,历经单调、繁琐、艰辛的劳动,终于付梓。钦佩之余随即作序共勉。
Dave Wang
SE Forum China
2002年3月于深圳
目 录
第1章 焦油坑 / 001
编程系统产品 / 003
职业的乐趣 / 005
职业的苦恼 / 006
第2章 人月神话 / 009
乐观主义 / 011
人月 / 013
系统测试 / 016
空泛的估算 / 018
重复产生的进度灾难 / 019
第3章 外科手术队伍 / 025
问题 / 027
Mills的建议 / 029
如何运作 / 032
团队的扩建 / 033
第4章 贵族专制、民主政治和系统设计 / 035
概念的完整性 / 037
获得概念的完整性 / 038
贵族专制统治和民主政治 / 039
在等待时,实现人员应该做什么 / 042
第5章 画蛇添足 / 047
结构师的交互准则和机制 / 049
自律—开发第二个系统所带来的后果 / 050
第6章 贯彻执行 / 055
文档化的规格说明—手册 / 057
形式化定义 / 058
直接整合 / 061
会议和大会 / 061
多重实现 / 063
电话日志 / 064
产品测试 / 064
第7章 为什么巴比伦塔会失败 / 067
巴比伦塔的管理教训 / 069
大型编程项目中的交流 / 070
项目工作手册 / 070
大型编程项目的组织架构 / 074
第8章 胸有成竹 / 079
Portman的数据 / 082
Aron的数据 / 083
Harr的数据 / 084
OS/360的数据 / 085
Corbató的数据 / 086
第9章 削足适履 / 087
作为成本的程序空间 / 089
规模控制 / 090
空间技能 / 092
数据的表现形式是编程的根本 / 093
第10章 提纲挈领 / 095
计算机产品的文档 / 097
大学科系的文档 / 099
软件项目的文档 / 099
为什么要有正式的文档 / 100
第11章 未雨绸缪 / 103
试验性工厂和增大规模 / 105
唯一不变的就是变化本身 / 106
为变更设计系统 / 106
为变更计划组织架构 / 107
前进两步,后退一步 / 109
前进一步,后退一步 / 111
第12章 干将莫邪 / 113
目标机器 / 116
辅助机器和数据服务 / 118
高级语言和交互式编程 / 121
第13章 整体部分 / 125
剔除bug的设计 / 127
构件单元调试 / 129
系统集成调试 / 132
第14章 祸起萧墙 / 137
是里程碑还是沉重的负担 / 139
“其他的部分反正会落后” / 141
地毯的下面 / 142
第15章 另外一面 / 147
需要什么文档 / 150
流程图 / 152
自文档化的程序 / 156
第16章 没有银弹—软件工程中的根本和次要问题 / 163
摘要 / 165
介绍 / 165
根本困难 / 166
以往解决次要困难的一些突破 / 171
银弹的希望 / 172
针对概念上根本问题的颇具前途的方法 / 181
第17章 再论“没有银弹” / 189
人狼和其他恐怖传说 / 191
存在着银弹—就在这里 / 191
含糊的表达将会导致误解 / 192
Harel的分析 / 195
Jones的观点—质量带来生产率 / 201
那么,生产率的情形如何 / 201
面向对象编程—这颗铜质子弹可以吗 / 203
重用的情况怎样 / 205
学习大量的词汇—对软件重用的一个可预见但还没有被预言的问题 / 208
子弹的本质—形势没有发生改变 / 209
第18章 《人月神话》的观点:是与非 / 211
第19章 20年后的《人月神话》 / 235
为什么要出版20周年纪念版本 / 237
核心观点—概念完整性和结构师 / 238
开发第二个系统所引起的后果—盲目的功能和频率猜测 / 240
图形界面的成功 / 243
没有构建舍弃原型—瀑布模型是错误的 / 247
增量开发模型更佳—渐进地精化 / 249
关于信息隐藏,Parnas是正确的,我是错误的 / 254
人月到底有多少神话色彩?Boehm的模型和数据 / 256
人就是一切(或者说,几乎是一切) / 258
放弃权力的力量 / 259
最令人惊讶的新事物是什么?数百万的计算机 / 262
全新的软件产业—塑料薄膜包装的成品软件 / 264
买来开发—使用塑料包装的成品软件包作为构件 / 267
软件工程的状态和未来 / 269
结束语 令人向往、激动人心和充满乐趣的50年 / 271