 |
相關閱讀 |
大道至简——软件工程实践者的思想 第7章 现实中的软件工程
|
>>> 讀書—連接古今充實信仰 >>> | 簡體 傳統 |
第7章 现实中的软件工程
“王不如远交而近攻，得寸，则王之寸；得尺，亦王之尺也。”
——《战国策．秦策》
1. 大公司手中的算盘
从最早仅仅关注于软件开发工具到现在，软件行业中的巨头们已经在层出不穷的思想中涅盘了一回又一回。
Rational 被 IBM 购并的真实原因在于 IBM 需要构建一个完整的软件工程体系。有了 Rational 的 IBM 会变成
这个样子：
IBM 的软件工程(2004)
理论体系 实 现
工具 Language Rational Suite、WebSphere、Eclipse
方法 OOA/D/P IBM软件开发平台(SDP)
过程 RUP RUP2000、RUP2003
IBM 得到 Rational 的最大好处是在软件工程方面，快
速地拥有了一套成熟的理论体系和实作工具。对于 IBM
来说，Rational 有着 UML 语言的非常丰富的实践经验，
还有着 RUP 作为理论框架的创立者和领导者的地位，这
些对 IBM 在确立大型软件工程应用方案提供商的行业形
象，都是极大的支持。
在语言方面，IBM 注意到 JAVA 作为平台中立的语言
特性，以及它在大型应用工程方面的成功表现，作为扼制
Microsoft 的平台优势的唯一途径，IBM 在语言方面选择
支持 JAVA 是明智的。
出于同样的理由，IBM 亲近开源软件界，并很快成为
开源软件领域的头羊地位。这使得 IBM 从没有语言优势
立即变成了“可以忽略语言劣势”。开源界给了 IBM 一种
对抗的背景和实力，而 IBM 只需要做到把握这种力量，
就可以在潮流中稳如磐石。
把握力量总之比创造力量来得经济。
同样，Borland 也从开发工具厂商的位置跳出来，希
望构建类似的软件工程体系。所以现在你会看到这样的一
个 Borland：
Borland 的软件工程(2004)
理论体系 实 现
工具 Language Togther、StarTeam、Delphi、CBX、JB...
方法 OOA/D/P Galileo、PrimeTime
过程 ALM Borland ALM Solution
对于 Borland 来说，在对软件开发语言(C、Java、Delphi)
的把握方面是优势，所以 Borland 一直保持在语言上的中
立，以寻求一种在不同平台上的开发者社群的支持最大
化。Borland 积极的推动 UML 的标准化，一方面可以使
得 Borland 有机会在模型语言标准的制定上有机会制造影
响，另一方面也可以快速地与 IBM/Rational 构成对抗
Mircosoft 的战线。
作 为 工 具 开 发 商 ， Borland 快 速 地 拥 有 了 实 现
ALM(Application Lifecycle Management)所需的绝大多数
软件产品。然而 Borland 也很快意识到，(当前的)ALM 是
一个产品体系，而不是一个理论体系：Borland 没有在
ALM 作为工程理论方面的任何优势。于是 Borland 开始
购并与实现 ALM 体系相关的公司，其中收购过程改进咨
询公司 TeraQuest 并组建流程优化实务部，以及收购
TogetherSoft 为开发工具来强化模型构建能力，都是相当
大的一些举措。通过这些努力，Borland 快速地补全了
ALM 作为一个工程体系在理论方面的不足。
对于 IBM 来说，RUP 和 UML 是优势，所以 IBM 用
来削弱 Borland 在开发语言的上优势的最佳手段，就是支
持开源的 Eclipse，以及用 UML 的标准化来确立其规范制
定者的地位。然而你会惊异的发现，Borland 一方面在支
持 UML 的标准化，另一方面还在支持着 Eclipse 的开发并
协助其快速成为一个完整的、具有商业品质的开发平台。
这似乎是极其怪异的战略：帮对手磨剑。
如果 Borland 只为一个对手磨剑，那他可能是一个傻
子。但问题是，Borland 几乎为他所有既已成为的或者终
将成为对手的人磨剑：Kylix 是 Linux 平台上的产品，
C++Builder、C#Builder、CBX、Delphi 是 Win32 和.NET
平台上的产品，JBuilder 则是 SUN 平台上的产品。——一
切正如 Borland 自己说的那样，他是“(语言、平台和技术)
中立的软件厂商”。
Borland 走在钢丝绳的中间，对他的考验是平衡的艺
术和技术：如果他倒下，钢丝绳两端之任一，对他都不及
援手；然而如果他存在，那么他向哪边迈出的一步，都将
给对方以最大的压力。
敌人的敌人就是自己的朋友，聪明的战略家总是能看
到这一点。然而 Borland 却力图使这个敌我都分不清的战
场呈现出一种古怪的格局：一方面 Microsoft 是 Borland
的股东之一，另一方面 Borland 在做 SUN、IBM 以及 Linux
平台上的软件提供商。
与 Borland 和 IBM 通购并来达到目的的方式并不相
同，Microsoft 有足够的力量全方位出击，因此你看到的
体系会这是这个样子的：
Microsoft 的软件工程(2004)
理论体系 实 现
工具 Language VS.NET、DSL、.NET Framework
方法 OOA/D/P 需求方法、模型方法、测试方法...
过程 MSF MSF Process Model v.3.1
Microsoft 在工具、方法和过程方面都有具体的实现。
而 IBM 在方法和过程层面上大都停留在理论阶段，
Borland 在这些方面虽有丰富的产品实现，却又相对缺乏
理论基础。
Microsoft 并不仅停留于此。从.NET Framework 提出
开始 Microsoft 就试图在开发语言和基础框架上实现大统
一，希望能达到 UML 在模型语言中的地位。因此出现了
通用的语言体系：CLR+CTS，以及其具体的实现：.NET
CLR+IAsm。.NET 上的代码要求最终被实现成中间代码，
可以反汇编到 IAsm，这意味着任何其它公司在开发语言
层 面 上 的 优 势 丧 失 殆 尽 ， 所 以 开 发 者 们 看 到 C# 、
JScript.NET 和 VB.NET 的同期实现的“壮举”。
而 Mono 的出现，对于 Microsoft 来是绝对的福音。
Microsoft 把.NET Framework 中的 C#、公共语言架构(CLI)
以及通用类型系统(CTS)等做成 ECMA 标准，最期望看到
的就是类似 Mono 这样的第三方产品的出现。事实上，
Mono 做了 Microsoft 从来都想做而不敢做的事。——解决
了 Microsoft 产品的跨平台问题，进而削弱了 SUN 这样的
语言的跨平台优势。Microsoft 一方面不想放弃自己的平
台优势，另一方面又为 SUN 的跨平台优势所制肘。而
Mono 的出现以及它适度的影响力，正好成为 Microsoft
平衡这种微妙的、相对优劣形势的棋子。
接下来 Microsoft 开始向模型语言发难。领域专用语
言（Domain-Specific Language，DSL）的提出绝非偶然，
那是在硝烟未尽的战场上重新燃起的战火。
软件业界如今的局面，不是一些人(例如程序员或者
评论家们)争争吵吵的结果，而是大公司们相互制衡的结
果。Borland 与 IBM，IBM 与 SUN，以及 SUN 与 Apple
都在做着相同的事， 又都有各自的算盘。他们一面打压
对手的优势，一面又借助对手和同盟的力量来削弱自己的
劣势或者补充实力。
跳出到局外来看，并不是说 Microsoft 是他们的共同
对手，而只是因为 Microsoft 占在了峰头浪尖，便成了众
矢之的。所有人面对的并不是 Microsoft 的这个名字，而
只是这个地位，无论谁成就了这个地位，都将承受相同的
风险与压力。
当然也包括机会。
大公司们在标准、理论、语言上的争来夺去，未必全
然出于“软件实现”的考虑。对统一理论、统一工具、统
一过程的企图，其最终目的是在整个软件工程体系中的全
面胜出。
算盘上的绝大多数人，只是用于计算胜负的一枚算
子。
2. 回到工程的关键点
因而，除了软件本质力量的推动之外，商业因素也推
动着软件工程体系的发展。大公司们的争夺战的最终结
果，已经开始把软件工程，从原始的“自生演进”状态，
逐渐推进到“它激发展”的状态上了。
这种它激发展可能会影响到软件工程发展的速度，然
而在各个工程层面上的关注点并不会发生变化。在前面的
模型图中，每一条纵向的细线用于定义一个关注点①。我
在另一次培训中为这些关注点加上了标注：
实现 团队 经营
这被我命名为软件工程层状模型(EHM, Engineering
Hiberarchy Model)。与“牛屎图”所代表的“软件工程体
系层次”不一样的是，EHM 不描述工程元素间的关系，
甚至在试图割裂这些元素，以使得工程角色定位以及各自
的视角更加清晰明确。
① 我的确画出的线而不是点，“关注点”只是一个概念。如果你非
要去发现一个“点”，那么你可以用几何的目光，关注于弧线与直
线的切点。然而，这样的结果将是你彻底的忽视了“关注点”的
本质含义。
-89-
第 7 章 现实中的软件工程
从这个模型中可以看到，在“程序”与“方法”层面，
是关注于“(具体的)实现”的；而在“过程”和“工程”
层面，更首要考虑的是团队问题。从角色的角度上来说：
开发经理思考项目的实施方案和管理具体的开发行为；而
项目经理则保障团队的稳定性和一致性。
然而这只是基本模式，或者说，是理想模式。
3. 思考项目成本的经理
在标注关注点时，如下的问题引起了我的思考：
项目的管理到底是组织管理还是成本管理？
项目的计划到底是组织规划还是成本计划？
简单的说：项目管理要不要考虑成本问题？
现在，我们从一个细节跳出来，来看看我们的角色。
这个细节就是：如何完成今天的工作。
正如前面所说，如果你是一个软件公司里的项目经
理，你可能今天的工作是写一份项目计划案，或者听测试
部的报告，又或者是安排会议来听取和分析一个新的产品
需求。然而，我需要说的是：
这是细节。
细节就是你使用的 Project 2003，或者你正在公司内
部署和推广的 ClearCase。如果它们正好是你今天要完成
的工作，或者是你明天要用来工作的工具，那么，作为项
目经理的你，现在就要立即跳出来。
理想状况下，“软件工程=过程+方法+工具”。然而工
程成功的真正关键，并不在于你把你的团队“组织”得有
多好。即使在团队中他们都显示有条不紊，你一样会面临
失败。
蚂蚁的团队总是被本能地组织得非常好。然而如果一
个蚂蚁的群体中有了流行疾病，蚂蚁在死去，而新生蚂蚁
不能跟上其死亡的速度，那么很快，这个团队就溃散了。
这是因为蚂蚁用于维护团队运作的“资本”在流失。
如果资本没有了，就没了运作，团队的存在就没有了必要
性和可能性。
项目就死亡了。
埋头于画甘特图的项目经理犯下了与挖山不止的愚
公类同的错误：忽略了成本。
如果愚公真的可以成功，那么可能是 300 年之后。然
而如果一个工程要 300 年才能做成，那么在做成之前，客
户就选择了放弃。
如果有机会，项目经理可以选择向另一家公司购买一
个产品来卖给客户，从“为客户开发”变成“为客户定制”，
以及“为客户服务”。这样在没有任何开发成本的前提下
完成了工程。与另一个同样极端的例子相比，你会发现它
与第五章中那个“做过场”的项目全然不同。后者是做完
了工程，却没有做成工程。而现在这个项目经理却做成了
工程，但是在许多的过程环节上，他根本就没有开始。
然而现在，除了跃跃欲试的技术经理之外，没有人会
不满意这个结果。
技术经理最常说的话是：我们可以开发出来；开发人
员最常说的话是：我可以开发出来；愚公最常说的话是：
何苦而不平？
还记得那句话？——不要栽进蚂蚁洞里！
愚公如果停下来，思考的问题可能是碎石的“方法”。
而项目经理从细节中跳出来，思考的问题就应当是完成工
程的“方法”。评价这个方法的好坏的标准只有一个：节
约成本。
Y 公司由 K 公司过渡而来的时候带来了一个市场前
景非常看好的产品。而存在的问题则是两方面的，一是扩
大市场占有，二是继续的技术投入。
于是，Y 公司请来了专家 D。他是一个在行业中摸年
爬滚打了多年的顾问型专家，做过公司，也在无数个公司
做过。D 先生的项目计划可能是无可挑剔的，但其投资规
模决定了它无法实施；D 先生在一些产品计划上的思考上
也是切近市场的，然而他没有学会如何为团队争取到两名
以上的开发人员；D 先生在部门管理上的方法也是适当
的，然而他忘记了训练部门人员以使他们与自己保持一致
的步调和方向(组织和管理一个松散的团队比照顾一群蚂
蚁难得多)。
于是在 Y 公司建立到倒掉的四年时间里，D 先生三
进三出，营销计划一再被否决，而产品的再研发计划也数
度搁置。很快，这个并不生动的故事被终结于我跟他的最
后一次会谈：三年之后，产品彻底从市场中退出。
——思考成本，这是 D 先生给我的教训：
不计成本的项目计划不会得到经营者的支持；
毫无目的地消耗成本是项目中的慢性毒药；
最致命的风险是成本的枯竭①。
4. 审视 AOP
我读到的第一篇关于 AOP 的文章居然说它是“新一
代的 java 语言”。OH，正如文章的标题所表现的那样，作
者大概是在学习如何向方格子里填写“错误”：其结果当
然是每一个格子都是“错误”。——如果他象小学生一样
勤奋的话。
AOP 不是语言。AOP 首先是方法论，这就象 OOP 是
“面向对象的编程方法”是方法论一样。而 Delphi／C++
才是语言，是对这个方法论的一个实现工具。
① 我经常注意到的成本因素包括时间、人力、资金和客户成本。
而大多数情况下，人们不会把客户的数量以及耐心当做(客户)成本
来计算。而在我的项目规划中，这是成本。
很好，有了这个基础，我们再来讨论相似性的问题。
我们提到过开发方法是基于一种数据结构的编程实践的
结果。很显然，OOP所基于的数据结构是对象(Object)，
而AOP所基于的数据结构就是方面(Aspect)①。落足到开发
工具的实现上，Delphi将Object表现为一组有(继承)关系的
“记录(Record)”②。相对应的，Java将用类(Class)来实现
Aspect。
Aspect 在定义时没有确定的对象模块，Aspect 本身只
是对一个“对象模块群体”的观察视角，因此它更易于表
现成接口。——只有描述而没有实现。
在 Object 一层的抽象上，Object 关注于“有继承关系
的考察对象”的个体特征；而在 Aspect 一层的抽象上，
Aspect 关注于“有相似需求的考察对象”的群体特性。其
相似性在群体中表现得越广泛，则 AOP 的优势也就越明
显。例如在 Delphi 的 VCL 框架中，以下两个需求就可以
① 人们在争论Aspect到底应该译成“切面”还是“方面”这件事上
花了很多功夫。其实，就如同讨论前面的“关注点”究竟是“点”
还是“线”的问题一样，他们陷入了细节。如果这些细节被作为
问题持续下去，那么可能有一天台海战争将不是发生在军队之间，
而是在程序员之间：到底是“物件”，还是“对象”？
② 在C中，这个名词是“结构(Struct)”。很多人不会承认“对象是
有继承关系的记录”这样的观点。是的，所有的教科书上都不会
这样写。但是从数据结构本身以及数据结构在语言中的实现来看，
对象终究是记录。记录是平板化的内存存储体系中所能表达的最
复杂的单一数据体。
用 AOP 的思想来实现：
使 Delphi 中的全部对象具有多线程特性(即线程
安全)；
实现助手工具类以观察、控制 Delphi 对象的运
行期特性或表现。
到现在为止，我们弄清楚了 AOP 作为“思想、方法、
工具”的一些基本知识，以及它的应用范围：至少你要明
白，他是用来考察对象(而不是设计对象)的思想方法。
所以接下来 AOP 的三个概念我们就明白了：
指示(advice)/拦截器(interceptor)：考察这些对象
以“达到什么样的目的”(即需求)；
引导(introduction)：在目标上实现这些需求时，
目标所需要表现出来的公共特性。引导特性可能
需要配合编译器来实现。
元数据(metadata)：如果需要，为既有对象实体
再补充一些参考数据。
确切的说，切分点(Pointcut)并不是 AOP 编程方法所
需要的概念，而是 AOP 作为一个框架时所需要的一个工
具：一组辨识 Acpects 和 Objects 的索引。
现在你已经会用 Acpect 的思想来编程了，而无论它
是用 Java 来实现的，或者是用 C#、Delphi，乃至于
FORTRAN 或 COBOL。你需要做的是，回到工程最核心
的那个环节：编程＝算法＋结构＋方法。
5. 审视 MDA/MDD
MDA(Model Driven Architecture)也是一个方法论层
面上的名词。它讨论的是“创建出机器可读和高度抽象的
模 型 ” 的 方 法 。 受 MDA 影 响 的 开 发 活 动 被 称 为
MDD(Model Driven Development)。
与 MDD 在同一个层面上的概念是：
TDD(Test Driven Development)
FDD(Feature Driven Development)
BDD(Business Driven Development)
R-TDD(Rapid Template-Driven
Development)
CDD(Contract Driven Development)
RDD(Requirements Driven Development)
...
我不厌其烦地罗列这些名词，只想告诉读者一个事
实：什么都可以“驱动开发”。
不同的方案提供商基于自己的产品构架和当前的理
论倾向，随时都在准备改变他们“驱动开发”的方式。在
这种形势下的 “xDD”或“xDA”，已经成为他们促销产
品的保留用词。
回到软件工程的过程环节中来吧，你会看到，“以什
么驱动开发”只是一个“以哪个环节为中心(或导引)”的
问题。所以你会看到 TDD 中的 X 模型(也可参考 V 模型)
是这样的：
如果你仍旧不能明白为什么会有这么多被神秘力量
所“驱动着的开发”，那么你就干脆去厨房找个平底锅烧
点热油，然后敲下一个鸡蛋，很快，你就体悟“以蛋黄驱
动开发”的真谛了。
抛开实现的技术细节不论，在工程中，“以什么驱动
开发”其实是一个过程问题。而你应该明白，过程的选择
(或制定)取决于你的工程需要，以及它在相关应用领域的
适用性、过程工具的充备性和这个过程理论的完善程度，
而不是大公司们的鼓吹。
过程模型决定了工程的实施步骤和组织方式。但是Object Management Group (OMG) 尽管对 MDA 提出了一套完备的技术和方法体系，工程实施者却无法在这个体系中找到一个可以适用的软件过程模型。——MDA 不讨论过程。
也就是说，MDA 架构作为一个新的软件开发方法的架构，即使在技术研究、底层协议和软件实现方面经过了持续地完善而渐至成熟，然而如果没有同样成熟的软件过程理论支持，那么它在工程中的实用价值也就有限。
仔细审视一下这个 MDA，如果你现在就决定将下一个工程项目建立在这个构架的基础上，或者用 MDD 的方式来开发 BIOS，那么你离精神病就不远了。
周爱民(Aimingoo) 2013-08-24 22:35:59
評論集
暫無評論。
稱謂：
内容：
驗證：
返回列表