内容


理解软件工程:以一个学生的视角

Comments

学生们的交谈 Agile Journal 的十一月刊,一份敏捷社区的电子杂志,发表了一篇由 Daryl Kulak 撰写的题为“让我们埋葬软件工程这个词语”的文章。1 我的第一反应就是“这是另一位敏捷的狂热者,他认为只有敏捷才是值得去做的事情。”为了反驳 Kulak 先生的观点,我重读了这篇文章,并且发现还有另一件事值得去思考,我怀疑这正是 Kulak 希望他的读者所得到的。

我认识到不同读者在阅读 Kulak 的文章时会得到许多不同的观点和价值。作为一名教师,我决定找出我的学生们是如何想的。这个月,我将同您分享我的学生们在理解软件工程方面对这篇文章的观点和反应。

在进入详细讨论之前,我将首先建立我对于 Kulak 文章的观点。然后,我将描述我分配给我的学生们的任务,以及之所以分配这些任务的原因。最后,我将向您展示学生们的工作。我希望这将引起您的深思,并且更加深入的考虑您的观点。

设置上下文环境

如果 Kulak 将他的文章称作“对软件工程的误解”或者“并不是所有的软件开发都要求工程”的话,那么我我也许不会做出如此强烈的反应。但是,他并没有这样做,而且这篇文章很快就引起了我的不满。如果您阅读过我的专栏文章的话,您就会知道我试图对软件开发主张一种实用的方法。我尝试着基于我自己的观点和判断而非死守任何一种当前的方法论。2 我经常教授一些学生们将永远不会在他们的职业生涯中使用的软件工程学实践。然而,我确实试图慢慢的向他们灌输使用适合的工程学方法来分析和设计程序、定制实践的能力。

所以 Kulak 确实在第一段中引起了我的注意,他写道:“通过使用工程学一词来描述我们的职业,我们就将我们自己局限在一个阻碍变革的静态的过程和脆弱的团队结构中了,而不是将其融入我们每天的生活里。”Kulak 从来都没有定义他在文章中所提到的“工程学”的含义,但是却假设读者对这一术语的意义有所理解。进而,他假设读者的理解和他的理解是相同的。

现在我们可以看到,软件工程和其他工程学科之间确实存在区别。3 我们已经以各种不同的方式定义了软件工程学,并且试图将某些定义考虑进来,正如您将从我的学生们的评论中即将看到的那样。的确,工程学作为一门学科已经发展了几个世纪,所以软件工程并不同于我们先前所具有的通用的定义。

当然,某些类型的工程学较之其他学科较少的处理变革。以 Kulak 在文章中所举出的建造一座桥梁的例子来说,确实试图在项目期间阻碍变化的发生。谁会希望在建造一座跨河大桥进行到一半的时候,客户却提出将其向河的下游再移动一些呢?这就是当不利的经济影响远远超过有利的变化的时候,阻碍变革的原因。当然,如果您要建造的是一座移动的大桥,4 比如那些军事机构所使用的桥梁的话,那么显然就必须将某些变化考虑进去。有一些我能够想象出来的变化,比如不同的地形、不同的车辆和部队类型等。实际上,一位工程师设计这种类型的桥梁时,大概更加关注它的可重用性,降低成本并且赋予其从同一个基本部分中创建一系列不同的桥梁的能力。这听起来多么像创建一个软件架构啊。

接下来,Kulak 阐述人员之间的不同,这使我再一次相信他的说法没有根据。他说道:“我们大都是面向人员而非面向产品的。”我同意许多软件开发人员,特别是咨询师倾向于面向人员,但是我并不认为大多数软件开发人员也被归于此类。我要说,我所遇到的好的软件开发人员都能够很好的平衡人员和产品之间的关系。我所遇到的大多数出色的民用的、机械的、电气的工程师也是如此。

这带来了我对 Kulak 的文章的另一个问题。他假设工程学意味着工程公司的结构(人员)和处理过程,并且声称这样的公司“并不是愉快的工作”。如果事情真的如此糟糕的话,那么谁还希望到工程学企业中去工作呢?实际上,我所认识的工程师都要求并且确实在享受他们的工作。

最后,Kulak 所说的话暗示出他真正的内心想法:“所以为什么我花费这么大的努力来避免使用这个少数人仍将使用的词语呢?实际上,这个词语对我们的团队的意义并没有那么大。我们越是将自己看作工程师,我们越是试图设计制造我们的解决方案、处理过程、甚至是人员。”

在这篇文章中还有许多内容是我不敢苟同的,我向您能够看到我站在哪一边了。但是,我想知道我的学生们会做出何种反应。我真的不在乎他们究竟是否同意这篇文章的结论。我想看一看他们是否有能力阅读这篇文章,得出结论,并且支持他们所得出的结论。我必须承认,我对他们所做的工作感到非常的骄傲。

分配任务

我将下列任务(作业)分配给我的学生们:

在阅读完“让我们埋葬软件工程这个词语”一文之后,撰写一篇批评性的文章。指出你是否同意作者的结论,包括为什么,以及提出支持你的观点的论据。你的工作就是使读者信服以下内容:

  • 你阅读并且理解了这篇文章。
  • 你思考了作者的结论,并且对其观点进行了逻辑分析。
  • 您研究了这一主题,并且基于你所掌握的证据形成了自己的结论。

我相信软件开发人员和工程师必须能够既通过口头也通过书面进行沟通。

完成结果

总共41位同学上交了这份作业。他们的结论相当多样,但是我将其归纳为如下三类:

  • 完全(基本上)同意 Kulak 的观点。
  • 同意 Kulak 所传递的信息——短语软件工程并没有被很好的理解,并且具有否定性的含意。
  • 完全(基本上)不同意 Kulak 的观点和结论。

超过一半的学生(21位)属于第三类。八位学生同意 Kulak 的观点,十二位学生则属于第二类。无论是否同意 Kulak 的观点,大多数学生都阅读了这篇本章,并且进行了思考和分析,进而形成了他们自己的结论。我希望您能够同意。下面是摘自他们作业中的部分内容,我试着根据 Kulak 文章中相似的部分将这些内容加以归纳。在征得了学生们的同意之后,我将他们的姓名从伍斯特工学院(WPI)毕业的年份标记出来。

缺乏清晰的定义

大多数学生认识到他们所阅读的这篇文章理论的基础是不可靠的。Kulak 从未给出软件工程或者工程学的定义。在没有清楚的说明基本概念的前提下,怎么可能得出正确有效的结论呢?因此,大多数学生找到一种或者多种这些术语,并且将它们作为反驳的基础。

Dickson McCannell (WPI '09) 在 dictionary.com 上找到三种关于工程学的定义:

  1. 一种艺术或者科学,将纯粹的科学知识付诸实践,例如物理学或者化学,以及建筑学如桥梁、房屋、矿山、轮船和化学种植等。
  2. 工程师的行动、工作或者职业。
  3. 熟练的或者巧妙的发明创造;机动。

McCannell 和其他许多同学评论道,Kulak 强调软件开发人员需要具备创造性,并且影射工程学将抑制创造性。McCannell 写道:“Kulak 不断地强调创造性对于软件工程师的重要性,无论他们被称作什么皆是如此。正如他所说的,‘创造性是创造一个为变革做好准备的团队’的唯一方式,一个没有能力实践其创造力的团队最终会发现即使找到解决问题的有效方法,适应变化也将是一件十分困难的事情……第三种关于‘工程学’的定义是‘熟练的或者巧妙的发明创造;机动。’如果这不意味着创造力和适应变化的话,那么我就不知道它究竟意味着什么了。”

Maurice Williams (WPI '08) 针对工程学的定义提出一个简短的但是深刻而富有洞察力的评论。“无论您如何看待‘工程学’这个词,总是会联想到设计和建造这两个词语,正如同软件行业中的设计和开发一样。”

一些同学所找到的关于工程学的定义是由 Engineers Council for Professional Development (ECPD) 所提出的定义。其内容是:“根据科学原则设计或者开发结构、机械、仪器或者制造工艺的创造性应用,或者通过结合利用它们;或者根据对它们设计的完全认识进行建造或操作;或者在指定的操作条件下预见它们的行为;所有都作为一种有意的功能,对于生命和财产的操作和安全的经济学。”5

Galia Traub (WPI '09) 比较了 ECPD 定义和 Kulak 所说的工程学是关于“易于阻碍变化的静态的过程和脆弱的团队结构”的说法。

面向细节

一些学生采用面向细节的工程师的描述,含蓄的对比蕴藏在软件开发领域中的创造性的自由精神。

Aleksandr Ostapenko (WPI '09) 引用文章中假定的工程学特征,但是却得出了和作者完全不同的结论。Ostapenko 这样回应文中的假设:一位桥梁建筑者应当是有方法的和小心翼翼的,而软件开发人员应当是创造性的、热爱改变的、不为细节所困扰的。

Ostapenko 说:“倘若这些人真的能够编写代码的话,那么理论上说这将是一个很好的想法。这是因为如果公司里充斥着这些善于处理人员和伟大想法的工程师的话,那么他们也必须有能力执行它们。就个人而言,我认为有方法有系统无论对于哪一个工作领域来说都是一项必要的技能。它并不限制一个人的创造力或者影响其他任何表面上的约束和限制。举例来说,以统一的格式编写的代码较之仓促编写的代码(缺少注释、适当的缩进等)更有价值。总之,软件工程师需要平衡的这些技能,同其他任何人需要做的是一样的。”我认为 Alex 理解了提供价值的意义。

Greg Kinneman (WPI '10) 以同样的思路写下了以下评论:“Kulak 论点中的一个主要谬误就是他坚持工程师同编程人员不同,他们是‘苛求的、精确的、有方法和有系统的’。”然而,编程人员比起其他任何人都更加精确的要求他们的代码,因为哪怕仅仅是一个错误放置的逗号或者圆括号都将导致整个程序出现错误。Rob Wailing 声称他‘从来都没有见过一位伟大的软件开发人员是不关注细节的。’”6

桥梁建造是一个典型的工程学的例子

工程学当然是一个走过若干个世纪发展历程的广阔领域。随着技术的不断发展,出现了不同的工程学分支。这篇文章使用了一个建造桥梁的例子,这是但仅仅是一个可能的工程学活动。学生们提出这一点也并不令人感到惊讶。

Christopher Smith (WPI '10) 指出有若干种类型的工程学项目必须处理显著的变化。他说:“例如,有许多传统的工程师被迫工作于变化的需求中,当我们建造新的飞机时,或者第一次试图飞向外层空间时。尽管软件工程更加倾向于变化,但是它仍然遵守相同的工程学的基本原则;唯一的不同之处在于软件工程师更加频繁的被迫重新评估他们的需求,并且努力去满足它们。”

Billy Hnath (WPI '10) 在阐述选择桥梁建造者这一问题的时候说道:“……一个具备全局思考能力同时生产力的方法和指导方针的人是我们最希望得到的;即使这并不是一个桥梁工程师所具备的特点,也是一位电器或者机械工程师所具备的特征。事实上,软件开发人员需要这两种特点才能够取得成功,但是……这些正是大多数工程师所应当具备的。”

关于文章的这一部分最简洁的论述之一,就是 Chris Trufan (WPI '10) 所说的:“[Kulak] 所成功论述的只是桥梁工程师和软件工程师并不是一种职业,然而这个事实是众所周知的。”

但是这里涉及到一个有效性问题

即使是不同意 Kulak 的观点和结论的学生也承认人们思考工程学的方式是存在一定问题的。然而,这并不是说我们要停止在软件开发中使用工程学这个术语,而应当是让人们注意到工程学的真正含义,以及如何将其正确应用到软件开发之中。

在我们今天的用法中,软件工程学的确存在一些负面的色彩。这并不是什么新鲜事。关于软件开发是否是一门工程学科的争论已经持续了数十年。Jessica Doherty (WPI '09) 引用计算科学之父 Edgser Dijkstra 的话:

其他计算机科学家例如 Edsger Dijkstra 同意(或者曾经同意) Kulak 的观点。Dijkstra 声称软件工程并不是一门工程学,而更像是一门科学。他解释道:自从一些公司将所有“计算机程序员”都升格为“软件工程师”但是却没有给出任何原因、没有变化任何工作责任之日起,这一术语就变得空洞了。他指出诸如一个雇员在其第一天的工作中使用铅笔和纸而非程序开始分析一个项目的缺陷——完全没有为该公司提供他们真正想要的东西,他们希望得到的是“编程人员”而不是“工程师”。Dijkstra 宣称通常来说,如果工程师不能满足雇主的需要的话,雇主更愿意寻找编程人员而非工程师。7

Nelson Nogueria 找到一些更为大家所熟知或是不为大家所知晓的人物的说法,提供了更多关于我们是否能够将软件开发称之为工程学的观点。“也许有某一种方法将特定的问题呈现给一位软件工程师(例如 IBM® Rational® Unified Process,RUP®8),保证变化将被呈现给该任务。这是一个关于实际的工程学是否处于持续不变之下的争论。David Parnas 说,软件工程学实际上就是工程学的一种形式。9 Steve McConnell 说,虽然不是,但是它应当是。Donald Knuth 说,编程是一门艺术和科学。10 我相信软件工程学是一门不同的和持续变化的学科,没有一定之规可以涵盖其所能发生的所有情况。”Nogueria 先生所得到的经验就是没有一种“放之四海而皆准”的方法适用于软件的开发。

理论方法

有些学生对这项任务或作业抱有浓厚的兴趣,并且试图将他们从其他课程中所学到的技术应用其中。

Zachary Kleinfeld (WPI '08) 以列举所有原始文章中的缺陷开始起笔,然后依次加以辩驳。他说:“……从六个原因上来讲,这些论点是不能令人信服的。首先,它通过使用武断的定义‘工程学’来预示了其结论。其次,它使用错误的类推来同工程学的其他形式进行比较。第三,它仅仅将软件工程同民用工程学相比较,然而却忽视了其他同软件工程更加相近的已制定的工程学科。第四,它的论点无法在逻辑上支持其结论。第五,它的主张并不被证据所支持。最后,它对强有力的反面证据视而不见。”

我最喜欢的例子是由一位机器人技术工程学专业的 Neal Humphrey (WPI '09) 提出的。他指出了文章中的一个逻辑错误。Humphrey 说:“ [Kulak] 使用了一个稻草人谬误。读者眼前所呈现的是一些同工程学相关的内容,然后 Kulak 试图展示它是如何不适用于软件工程学。他仅仅引入了那些容易遭受攻击的想法。然后他说他所呈现的就是术语工程学不适用于软件的证据。由于这种稻草人谬误的使用,Kulak 非常担心攻击事件,他并没有花费时间来说明事物的正反两个方面。”无论这是否是一个稻草人谬误的真实的例子,我发现这是多么让人感到愉快的看到一位学生将他所学到的逻辑分析方法应用到实际问题之中。

结论

学生们是否同意本文的观点对于我来说真的是一件无所谓的事情。我希望他们思考非常实际的问题,并且形成他们自己的观点。我总是习惯将我自己个人的偏见掺杂到课程中,这样的话这些偏见就变成了事实而不是观点。这是一种很好的测试,看一看我是否对这种错误具有负罪感。值得庆幸的是,看起来如果我掺杂我个人的观点的话,学生们能够认识到它们知识一些观点而已。

关于“软件工程”这一术语,Doherty 女士描述了最重要的事情。只要“一家公司使用好的实践,无论其员工是软件工程师,软件开发者,或者是代码编写者,它们都能够成功生产出好的软件。”

注释

1请参见:http://www.agilejournal.com/articles/articles/let%27s-bury-the-term-software-engineering.html

2请参见我于2005年12月的专栏文章:教育软件开发与软件工程http://www.ibm.com/developerworks/rational/library/dec05/pollice/index.html

3请参见2005年12月的专栏文章。

4请参见:http://www.army-technology.com/contractors/engineering/man/man3.html, http://www.baileybridge.com/, or http://en.wikipedia.org/wiki/Pontoon_bridge

5来自 http://www.britannica.com/eb/article-9105842/engineering 的 ECPD 的定义。

6软件开发人员的个性特点:http://www.softwarebyrob.com/2006/08/20/personality-traits-of-the-best-software-developers/

7E. W. Dijkstra Archive。“还有一场战争需要继续”(手稿 Austin,1993年12月3日)。http://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1165.html

8http://en.wikipedia.org/wiki/Rational_Unified_Process

9Parnas,David L。(1998年)“软件工程程序并不是计算机科学程序”,http://citeseer.ist.psu.edu/parnas98software.htmlhttp://en.wikipedia.org/wiki/David_Parnas

10Donald Knuth,计算机编程像一门艺术http://fresh.homeunix.net/%7Eluke/misc/knuth-turingaward.pdf

11http://www.nizkor.org/features/fallacies/straw-man.html


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=290167
ArticleTitle=理解软件工程:以一个学生的视角
publish-date=02152008