软件工程实践者的思想(PDF格式)-第12部分
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
Microsoft 在工具、方法和过程方面都有具体的实现。
…86
…………………………………………………………Page 91……………………………………………………………
『大道至简』
而 IBM 在方法和过程层面上大都停留在理论阶段，
Borland 在这些方面虽有丰富的产品实现，却又相对缺乏
理论基础。
Microsoft 并不仅停留于此。从 Framework 提出
开始 Microsoft 就试图在开发语言和基础框架上实现大统
一，希望能达到 UML 在模型语言中的地位。因此出现了
通用的语言体系：CLR＋CTS ，以及其具体的实现：
CLR＋IAsm 。 上的代码要求最终被实现成中间代码，
可以反汇编到 IAsm ，这意味着任何其它公司在开发语言
层 面 上 的 优 势 丧 失 殆 尽 ， 所 以 开 发 者 们 看 到 C# 、
JScript 和 VB 的同期实现的“壮举”。
而 Mono 的出现，对于 Microsoft 来是绝对的福音。
Microsoft 把 Framework 中的 C# 、公共语言架构（CLI）
以及通用类型系统（CTS）等做成 ECMA 标准，最期望看到
的就是类似 Mono 这样的第三方产品的出现。事实上，
Mono 做了 Microsoft 从来都想做而不敢做的事。——解决
了 Microsoft 产品的跨平台问题，进而削弱了 SUN 这样的
语言的跨平台优势。Microsoft 一方面不想放弃自己的平
台优势，另一方面又为 SUN 的跨平台优势所制肘。而
Mono 的出现以及它适度的影响力，正好成为 Microsoft
平衡这种微妙的、相对优劣形势的棋子。
接下来 Microsoft 开始向模型语言发难。领域专用语
言（Domain…Specific Language ，DSL ）的提出绝非偶然，
那是在硝烟未尽的战场上重新燃起的战火。
…87
…………………………………………………………Page 92……………………………………………………………
第 7 章 现实中的软件工程
软件业界如今的局面，不是一些人（例如程序员或者
评论家们） 争争吵吵的结果，而是大公司们相互制衡的结
果。Borland 与 IBM ，IBM 与 SUN ，以及 SUN 与 Apple
都在做着相同的事， 又都有各自的算盘。他们一面打压
对手的优势，一面又借助对手和同盟的力量来削弱自己的
劣势或者补充实力。
跳出到局外来看，并不是说 Microsoft 是他们的共同
对手，而只是因为 Microsoft 占在了峰头浪尖，便成了众
矢之的。所有人面对的并不是 Microsoft 的这个名字，而
只是这个地位，无论谁成就了这个地位，都将承受相同的
风险与压力。
当然也包括机会。
大公司们在标准、理论、语言上的争来夺去，未必全
然出于“软件实现”的考虑。对统一理论、统一工具、统
一过程的企图，其最终目的是在整个软件工程体系中的全
面胜出。
算盘上的绝大多数人，只是用于计算胜负的一枚算
子。
2。 回到工程的关键点
因而，除了软件本质力量的推动之外，商业因素也推
动着软件工程体系的发展。大公司们的争夺战的最终结
果，已经开始把软件工程，从原始的“自生演进”状态，
…88
…………………………………………………………Page 93……………………………………………………………
『大道至简』
逐渐推进到“它激发展”的状态上了。
这种它激发展可能会影响到软件工程发展的速度，然
而在各个工程层面上的关注点并不会发生变化。在前面的
模型图中，每一条纵向的细线用于定义一个关注点① 。我
在另一次培训中为这些关注点加上了标注：
实现 团队 经营
这被我命名为软件工程层状模型（EHM； Engineering
Hiberarchy Model） 。与“牛屎图”所代表的“软件工程体
系层次”不一样的是，EHM 不描述工程元素间的关系，
甚至在试图割裂这些元素，以使得工程角色定位以及各自
的视角更加清晰明确。
① 我的确画出的线而不是点，“关注点”只是一个概念。如果你非
要去发现一个“点”，那么你可以用几何的目光，关注于弧线与直
线的切点。然而，这样的结果将是你彻底的忽视了“关注点”的
本质含义。
…89
…………………………………………………………Page 94……………………………………………………………
第 7 章 现实中的软件工程
从这个模型中可以看到，在“程序”与“方法”层面，
是关注于“（具体的） 实现”的；而在“过程”和“工程”
层面，更首要考虑的是团队问题。从角色的角度上来说：
开发经理思考项目的实施方案和管理具体的开发行为；而
项目经理则保障团队的稳定性和一致性。
然而这只是基本模式，或者说，是理想模式。
3。 思考项目成本的经理
在标注关注点时，如下的问题引起了我的思考：
） 项目的管理到底是组织管理还是成本管理？
） 项目的计划到底是组织规划还是成本计划？
简单的说：项目管理要不要考虑成本问题？
现在，我们从一个细节跳出来，来看看我们的角色。
这个细节就是：如何完成今天的工作。
正如前面所说，如果你是一个软件公司里的项目经
理，你可能今天的工作是写一份项目计划案，或者听测试
部的报告，又或者是安排会议来听取和分析一个新的产品
需求。然而，我需要说的是：
这是细节。
细节就是你使用的 Project 2003 ，或者你正在公司内
部署和推广的 ClearCase 。如果它们正好是你今天要完成
…90
…………………………………………………………Page 95……………………………………………………………
『大道至简』
的工作，或者是你明天要用来工作的工具，那么，作为项
目经理的你，现在就要立即跳出来。
理想状况下，“软件工程=过程＋方法＋工具”。然而工
程成功的真正关键，并不在于你把你的团队“组织”得有
多好。即使在团队中他们都显示有条不紊，你一样会面临
失败。
蚂蚁的团队总是被本能地组织得非常好。然而如果一
个蚂蚁的群体中有了流行疾病，蚂蚁在死去，而新生蚂蚁
不能跟上其死亡的速度，那么很快，这个团队就溃散了。
这是因为蚂蚁用于维护团队运作的“资本”在流失。
如果资本没有了，就没了运作，团队的存在就没有了必要
性和可能性。
项目就死亡了。
埋头于画甘特图的项目经理犯下了与挖山不止的愚
公类同的错误：忽略了成本。
如果愚公真的可以成功，那么可能是 300 年之后。然
而如果一个工程要 300 年才能做成，那么在做成之前，客
户就选择了放弃。
如果有机会，项目经理可以选择向另一家公司购买一
个产品来卖给客户，从“为客户开发”变成“为客户定制”，
以及“为客户服务”。这样在没有任何开发成本的前提下
完成了工程。与另一个同样极端的例子相比，你会发现它
与第五章中那个“做过场”的项目全然不同。后者是做完
…91
…………………………………………………………Page 96……………………………………………………………
第 7 章 现实中的软件工程
了工程，却没有做成工程。而现在这个项目经理却做成了
工程，但是在许多的过程环节上，他根本就没有开始。
然而现在，除了跃跃欲试的技术经理之外，没有人会
不满意这个结果。
技术经理最常说的话是：我们可以开发出来；开发人
员最常说的话是：我可以开发出来；愚公最常说的话是：
何苦而不平？
还记得那句话？——不要栽进蚂蚁洞里！
愚公如果停下来，思考的问题可能是碎石的“方法”。
而项目经理从细节中跳出来，思考的问题就应当是完成工
程的“方法”。评价这个方法的好坏的标准只有一个：节
约成本。
Y 公司由 K 公司过渡而来的时候带来了一个市场前
景非常看好的产品。而存在的问题则是两方面的，一是扩
大市场占有，二是继续的技术投入。
于是，Y 公司请来了专家 D 。他是一个在行业中摸年
爬滚打了多年的顾问型专家，做过公司，也在无数个公司
做过。D 先生的项目计划可能是无可挑剔的，但其投资规
模决定了它无法实施；D 先生在一些产品计划上的思考上
也是切近市场的，然而他没有学会如何为团队争取到两名
以上的开发人员；D 先生在部门管理上的方法也是适当
的，然而他忘记了训练部门人员以使他们与自己保持一致
的步调和方向（组织和管理一个松散的团队比照顾一群蚂
蚁难得多） 。
…92
…………………………………………………………Page 97……………………………………………………………
『大道至简』
于是在 Y 公司建立到倒掉的四年时间里，D 先生三
进三出，营销计划一再被否决，而产品的再研发计划也数
度搁置。很快，这个并不生动的故事被终结于我跟他的最
后一次会谈：三年之后，产品彻底从市场中退出。
——思考成本，这是 D 先生给我的教训：
） 不计成本的项目计划不会得到经营者的支持；
） 毫无目的地消耗成本是项目中的慢性毒药；
①
） 最致命的风险是成本的枯竭 。
4。 审视 AOP
我读到的第一篇关于 AOP 的文章居然说它是“新一
代的 java 语言”。OH ，正如文章的标题所表现的那样，作
者大概是在学习如何向方格子里填写“错误”：其结果当
然是每一个格子都是“错误”。——如果他象小学生一样
勤奋的话。
AOP 不是语言。AOP 首先是方法论，这就象 OOP 是
“面向对象的编程方法”是方法论一样。而Delphi ／C＋＋
才是语言，是对这个方法论的一个实现工具。
① 我经常注意到的成本因素包括时间、人力、资金和客户成本。
而大多数情况下，人们不会把客户的数量以及耐心当做（客户） 成本
来计算。而在我的项目规划中，这是成本。
…93
…………………………………………………………Page 98……………………………………………………………
第 7 章 现实中的软件工程
很好，有了这个基础，我们再来讨论相似性的问题。
我们提到过开发方法是基于一种数据结构的编程实践的
结果。很显然，OOP所基于的数据结构是对象（Object） ，
而AOP所基于的数据结构就是方面（Aspect）① 。落足到开发
工具的实现上，Delphi将Object表现为一组有（继承）关系的
“记录（Record） ”② 。相对应的，Java将用类（Class）来实现
Aspect 。
Aspect 在定义时没有确定的对象模块，Aspect 本身只
是对一个“对象模块群体”的观察视角，因此它更易于表
现成接口。——只有描述而没有实现。
在 Object 一层的抽象上，Object 关注于“有继承关系
的考察对象”的个体特征；而在 Aspect 一层的抽象上，
Aspect 关注于“有相似需求的考察对象”的群体特性。其
�
