按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
第 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 关注于“有相似需求的考察对象”的群体特性。其
相似性在群体中表现得越