软件工程实践者的思想(PDF格式)-第8部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！





的巨头们已经在层出不穷的思想中涅槃了一回又一回。　　



　　　　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　　在确立大型软件工程应用方案提供商的行业形　



　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…83


…………………………………………………………Page　88……………………………………………………………

第　7　章　　现实中的软件工程　　



象，都是极大的支持。　　



　　　　　在语言方面，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　一直保持在语言上的中　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…84


…………………………………………………………Page　89……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



立，以寻求一种在不同平台上的开发者社群的支持最大　



化。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　　只为一个对手磨剑，那他可能是一个傻　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…85


…………………………………………………………Page　90……………………………………………………………

第　7　章　　现实中的软件工程　　



子。但问题是，Borland　　　　　　几乎为他所有既已成为的或者终　



将成为对手的人磨剑：Kylix　　　　　　　　　是　Linux　平台上的产品，　



C＋＋Builder　、C#Builder　、CBX　、Delphi　　是　Win32　　和　



平台上的产品，JBuilder　则是　SUN　平台上的产品。——一　



切正如　Borland　　自己说的那样，他是“（语言、平台和技术）　



中立的软件厂商”。　　



　　　　Borland　走在钢丝绳的中间，对他的考验是平衡的艺　



术和技术：如果他倒下，钢丝绳两端之任一，对他都不及　



援手；然而如果他存在，那么他向哪边迈出的一步，都将　



给对方以最大的压力。　　



　　　　敌人的敌人就是自己的朋友，聪明的战略家总是能看　



到这一点。然而　Borland　却力图使这个敌我都分不清的战　



场呈现出一种古怪的格局：一方面　Microsoft　　　　　　　　　　　　是　Borland　



的股东之一，另一方面　Borland　在做　SUN　、IBM　　以及　Linux　



平台上的软件提供商。　　



　　　　　　



　　　　与　Borland　和　IBM　　通购并来达到目的的方式并不相　



同，Microsoft　有足够的力量全方位出击，因此你看到的　



体系会这是这个样子的：　　



　　　　　　　　　　　　Microsoft　的软件工程　（2004）　　



　　　　　　　理论体系　　　　　　　　　　　　　　　　实　　　　现　　



　工具　　　Language　VS、DSL、　Framework　　



　方法　　　OOA/D/P　　需求方法、模型方法、测试方法。。。　　



　过程　　　MSF　　　　　　MSF　Process　Model　v。3。1　　



　　　　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　关注于“有相似需求的考察对象”的群体特性。其　



相似性