阅读笔记-软件工程的银弹

(最近看了两篇关于“银弹”的文章,做一点笔记,其中,英文基本上是引用原文)

一.No Silver Bullet: Essence and Accidents of Software Engineering

  这篇是Fred Brooks在1987年所发表的一篇关于软件工程的经典论文。

 (链接:http://www.cs.umd.edu/class/spring2003/cmsc838p/General/NoSilverBullet.html

  所谓“银弹”,按我对这篇文章的理解,或许是一个可以让软件迅猛发展的神奇的东西。在外国的传说中,银弹可以杀死狼人。搁在中国来说,银弹就是一种可以制服任何妖魔鬼怪的法器。至于“没有银弹”,我查了一下维基百科(http://en.wikipedia.org/wiki/No_Silver_Bullet):“所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。”

  在文章中,作者一开始就指出了不能再对“银弹”抱有期待,而且语气还很坚定,类似下面的句子经常出现:

  "No such faith comforts the software engineer"

  "I do not believe we will find productivity magic here"

  并写道:

  “The first step toward the management of disease was replacement of demon theories and humours theories by the germ theory.”

  说的大概就是我们应该从科学的角度具体地分析软件工程的本质,不要妄想软件产业的发展可以一蹴而就。后面还提出:”anomaly is not that software progress is so slow, but that computer hardware progress is so fast” 我觉得这个观点还挺有趣的,或许正是因为硬件产业的快速发展,人们才会对软件产业的发展速度有焦虑。这就是对比的力量啊。

  后面的内容有很多都没有看懂,毕竟是大家之作,写得很专业。下面摘录我印象比较深的几点:

  1.The complexity of software is an essential property, not an accidental one.”

  软件的复杂性是本质属性,而复杂性指的是软件实体中没有任何两个部分相同,并且随着组成元素的增加,复杂性的增加通常还是非线性的。而复杂性也会带来一系列的问题:项目延期、成员间交流困难等。(作者列困难就列了两大段排比啊。)

  2. “Past Breakthroughs Solved Accidental Difficulties“

  作者认为已经取得的一些进步和成就,诸如高级语言、分时技术和统一的开发环境等解决的只是偶然.

  3. " The most radical possible solution for constructing software is not to construct it at all"

  这句话让我想到的是软件的复用性。如果类似的软件已经存在,那么就不用自己完全从头开始构建,可以把别人的买来,把需求不一样的地方加以改进和增加。

  4." Requirements refinement and rapid prototyping. The hardest single part of building a software system is deciding precisely what to build."

  软件构建的目的就是要实现相应的功能,而功能是由需求所决定的,所以需求定义得清晰明确对于软件构建是十分重要的。可是现实情况是,很多时候可能连用户自己都不能准确地定义自己的需求,大多情况下是一种模糊的描述。而且,需求是变化的,并且变化的频率也许比软件开发的频率要高得多。所以网上流传的段子:程序猿今天又要加班,因为老板的需求又变了o(╯□╰)o

  5 ."Whereas the difference between poor conceptual designs and good ones may lie in the soundness of design method, the difference between good designs and great ones surely does not. Great designs come from great designers. Software construction is acreative process."

  “good”和”great”是不一样的。创造力很重要。

二. There Is a Silver Bullet

  这个是 Brad J Cox在04年写的一篇文章(链接:http://www.drdobbs.com/there-is-a-silver-bullet/184407534/),上面那篇“没有银弹”是87年的,时隔17年有人对“银弹”问题又发表的不同的看法。

  我觉得下面几段体现了作者的重要观点,特摘录在此:

  “But if you view these same facts from a new perspective, a more optimistic conclusion emerges. The software crisis is not an immovable obstacle but an irresistible force--a vast economic incentive that will grow toward infinity as the global economy moves into the information age.

  To turn Brooks‘ own metaphor in a new direction, there is a silver bullet. It is a tremendously powerful weapon, propelled by vast economic forces that mere technical obstacles can resist only briefly. But as Brooks would agree, it is not a technology, a whiz-bang invention that will slay the software werewolf without effort on our part or vast side effects on our value systems and the balance of power between software producers and consumers.

  The silver bullet is a cultural change rather than a technological change”

  我对这几段的理解:作者觉得软件危机是促进经济发展的诱因。而“银弹”这种强大的武器则有经济作为基础,当然,要让”银弹”发挥威力还牵涉到经济学(生产者和消费者)、文化(价值体系)等方面的问题。

  其实我觉得说的挺抽象的,文化转变?这是一个很宏大的命题。

  后面提到了范式,面向对象技术等,基本上没怎么看懂,就没怎么做笔记了。(不过范式让我想到了离散。附上范式paradigm的维基百科http://en.wikipedia.org/wiki/Paradigm

时间: 2024-10-10 17:25:28

阅读笔记-软件工程的银弹的相关文章

阅读笔记-软件工程的大泥球

软件工程的大泥球 (原文地址:http://www.laputan.org/mud/) 大泥球的定义:A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. 文中作者拿软件构建和建筑做类比,我觉得是很合理的.软件架构师对应于建筑设计师,要做整

梦断代码--阅读笔记--软件工程

每每感叹编程时间不够,软件时间章节中有这么一段:"那是1975年的冬天.作者在终端机房中俯身敲击一台电传打字机,每打完一行,那笨重的机头就会摇头晃脑猛然撞回最左边,开始新的一行.我从几个小时前开始输入一行行黑代码,忘记了时间流逝,全然不知已是午夜时分.看门人已经关闭廊灯.我并没有得到许可在纽约大学物理系大楼中流连忘返.使用向高中学生免费发放的计算机账号.不过,倒也无人责难."时间都去哪了,时间就是忘记所谓的时钟,那么时间就变成了软件时间.死定了章节中的故事,我感觉写软件不仅仅要有时间,

现代软件工程-阅读笔记

构建之法:现代软件工程-阅读笔记 现代软件工程 软件 = 程序 + 软件工程 程序 = 数据结构 + 算法 软件工程包括了开发,运营,软件维护的过程中的很多技术.做法.习惯和思想.软件###工程把这些相关的技术和过程统一到一个体系中,叫"软件开发流程",软件开发流程的###目的是为了提高软件开发.运营.和维护的效率,以及提升用户满意度.软件的可靠性###和可维护性. 软件团队的模式: 主治医师模式.明星模式.社区模式.业余剧团模式. 秘密团队.特工团队.交响乐团模式.爵士乐模式. 功能

《2017 0907-构建之法:现代软件工程-阅读笔记》

阅读笔记 本周阅读了<构建之法>8.9.10章.这三章从需求分析.项目经理及典型用户和场景的知识进行了,这三章从需求分析.项目经理及典型用户和场景的知识进行了讲解,我作为初学者,我还是遇到比较多的问题,下面就是我的阅读笔记: 1:软件工程同其他工程项目一样存在风险. 2:客户的需求是难以捕捉的. 3:项目经理是软件团队的一个重要角色.他可以领导大家把问题"分而治之",当然公司不同PM职能略不同.邹欣老师在第九章主要讲了微软PM的来历.职能.能力要求及任务 4:软件开发要考虑

《大道至简---软件工程实践者的思想》阅读笔记二

08大道至简——软件工程实践者的思想阅读笔记之二 2015-06-02 16:41 第五章 失败的过程也是过程 以得失而论,在瀑布模型与RUP模型之间,学习前者而不成,可思过程的本质:学习后者而不成,可得文字的架子. 如果懂得了所谓的模型原本都演化自那个简单的瀑布,那么文档是按XP写还是按RUP写,也就可以应时.应需,因地置宜,择善而从了. 越是简单的东西,往往越是接近于本质. 项目经理的工作,就是要去组织这个工程中的各个角色,使得分工明确,步调一致,共同地完成这个项目. 第六章从编程到工程 我

《大道至简---软件工程实践者的思想》阅读笔记一

07大道至简——软件工程实践者的思想阅读笔记之一 2015-05-29 16:41 第一章编程的精益 作者将<列子·汤问篇>中的<愚公移山>与软件工程巧妙的结合起 来,通过分析证明其实在两千多年前的愚公除了在移山的过程中担任 “项目组织者,团队经理,编程人员等众多角色”,还已经具备了编 程人员的基本素质. <愚公移山>                                项目管理 惩山北之塞,出入之迂                       项目原始需求的

《构建之法》阅读笔记(2)

<构件之法>阅读笔记2 看了前面两章,我感觉我现阶段距离一个程序员还很远,软件工程师更是遥不可及.在学校的我学习了很多,如c++,数据结构,面向对象--学的多而不精,纵观现在我就是一个盲目学习的学生,上课时认真听了课后却没有花更多的时间去研究,遇到不懂的容易掉价死胡同,总是花很多时间闷闷思考,不到最后都没有去请教同学,去百度.看着其他很厉害的同学,自己就只能在一旁羡慕嫉妒恨.那现在在怎么样才能将自己对编程的兴趣提高,加强自己的编程思想?提高自己的价值?能够尽早地迈进程序员.软件工程师的行列之中

01软件构架实践阅读笔记之一

软件构架实践是我们下学期要学习的一本书,所以我想将这本书作为我阅读笔记的一本书. 在这本念书的第一章是总序,在其中提到: 1.所谓"正确的"就是在指功能.性能和成本几个方面都能满足用户要求且无缺陷: 2.所谓"无缺陷"就是在指编码后对软件系统进行彻底的穷举测试修复了所有的缺陷,保证所编写的代码本身不存在缺陷: 但是我们知道编写一个软件,并不可能很好的达到这种的效果,所以应该做到作者提到的"创造.应用.和推广"战略.但是我存在这样的问题: 1.创造

《构建之法》阅读笔记(1)

<构建之法>第一章阅读笔记 大马哈鱼洄游模型 软件工程按照经典的瀑布模型 1. 需求分析 2. 设计阶段 3. 实现阶段 4. 稳定阶段 5. 发布阶段 6. 维护阶段 事实上在现实世界中,软件工程师的职业发展与瀑布流程刚好相反 毕业进入公司(或者实习生),开始学习并维护一些已有的软件(维护阶段),主要由自己的师傅(Mentor)带领 能够在项目中改一些 Bug,然后发现发布小规模的更新版本(稳定/发布阶段),联系重构,开始和其他同事打交道 有机会负责重写一个较小的模块,没有多少文档,自己要写