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

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



编写History　这样的方法，来弥补ClearCase　、SourceSafe　、CVS等这　

些软件的不足。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…56


…………………………………………………………Page　61……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



成了形式。且往往是客户所讨厌的一种形式。　　



　　　　　



　　　沟通问题不仅仅存在与客户交流之中。还存在于与项　



目的各个角色之间。项目的分析报告为设计人员所看不　



懂，设计人员的方案为开发人员所看不懂，而开发的结果　



以为测试人员所看不通。等等都是沟通问题。　　



　　　UML　　的确是解决沟通问题的最佳手段之一。然而如　



果项目一开始就不能用它，那么强求的结果必然是痛苦　



的。——要让　UML　在一个没有经过相关培训的团队及其　



各个角色之间用起来，几乎是不可能的事。即使用得起来，　



也存在经验问题。千万不要指望仅仅一个项目，就能让你　



的组员深刻的理解　UML　　的思想。　　



　　　也不要指望在每个项目中都能用它，如果你的客户能　



理解并支持使用　UML　，那以这个项目就会有一个良好的　



UML　使用环境。否则，开发环节中资料的不一致性，将　



会使得项目难以收场。　　



　　　使用与不使用　UML　，其根本的问题在于沟通方式的　



选择。只要是行之有效的、能在各个项目角色间通用的，　



就是好的沟通方式。　　



　　　　　



　　　在每一次回顾项目时都应该注意：流于形式的沟通，　



可能是使得你的项目被不断推翻和不断延迟的最直接原　



因。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…57


…………………………………………………………Page　62……………………………………………………………

第　4　章　　流于形式的沟通　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　

　　　　　　　　　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…58


…………………………………………………………Page　63……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　



　　　　　　第5章　　失败的过程也是过程　　



　　　　　　　“虚有其表耳。”　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《明皇实录》　　



　　　　　1。　　　做过程不是做工程　　



　　　　　软件工程这个概念被提出的时候大概是在上个世纪　



60　　年代末。它作为成熟的概念的标志是软件工程的瀑布　



模型的提出。瀑布模型将软件开发的过程分成需求、分析、　



设计、开发和测试等　5　个主要阶段，其主要环节关系表现　



为如下的这样一种形态：　　



　　　　　　　　　　　计划计划　

　　　　　定定　　　　可行性研究可行性研究　

　　　　　义义　

　　　　　　　　　　　　　　　需求分析需求分析　



　　　　　　　　　　　　　　　　　　　　　　系统设计系统设计　



　　　　　　　　　　　　　　　　　　　　　　　　　　程序设计程序设计　

　　　　　　　　　　　　　　　　实实　

　　　　　　　　　　　　　　　　现现　　　　　　　　　编码与模块测试编码与模块测试　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　组合与系统测试组合与系统测试　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　维维　　　　　　　　运行运行&&维护维护　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　护护　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　



　　　　　在瀑布模型之后，很多人开始研究过程模型的问题。　



很多从实际工程中提炼出来的过程模型都是值得称道的，　



　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…59


…………………………………………………………Page　64……………………………………………………………

第　5　章　　失败的过程也是过程　　



例如　RAD（快速应用开发）模型、螺旋模型和现在常被提及　



的　RUP　模型。　　



　　　　模型就是“样子”。人家拿出一个东西来说：这是模　



型。其言下之意就是要你按照这个样子来做。然而正如下　



在这张图所展示的：　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　按照模型的这个“样子”，做完过程的每一个阶段，　



并不等于做工程。或者说，工程并不是这样就可以做成功　



的。　　



　　　　换而言之，无论是用　RAD　模型还是　RUP　模型来做工　



程，即使是亦步亦趋，也做不好工程。　　



　　　　　　



　　　　如果工程可以那样做成的话，只需要有瀑布模型就足　



够了。因此做过程并不是做工程的精义。　　



　　　　也不是目的。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…60


…………………………………………………………Page　65……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



　　　2。　　　做过场　　



　　　　为什么会存在这样的问题呢？　　



　　　　四川有句地方话叫“做过场”，也有说成“走过场”　



的。“过场”是舞台术语，意思是角色从舞台一端出场，　



再走到另一端进场的一个过程。过场角色一般没有唱腔或　



道白，即便是有，也是没有什么实质内容的。　　



　　　　　



　　　　前面那张图就是一个过场。尽管那是一张用来描述　



　“沟通问题”的经典图例，然而你应该注意到，每一个角　



色都把自己的环节当成一个“过场”。如同演戏一样，从　



A　　做到　Z　，就一切都完成了。当然，按照　RUP　　　　　　　　　　的思想，　



是要从　A　　到　Z　　一遍又一遍地做下去的。然而，如果每一　



遍（或者用　RUP　　的那个术语“迭代”）都只是“过场”的话，　



项目将是一场无休止的演出而已。　　



　　　　　



　　　　最终呢？观众受不了了，就交钱走人；演员受不了了，　



就下台散伙。戏目和项目的结局，竟如此地相似。　　



　　　3。　　　实现，才是目的　　



　　　　很多人把问题的本质给忘掉了。从最开始，从我们编　



程开始，我们的目的就是实现一个东西。无论这个东西是　



小到一个称手的工具，还是一个大到千万的工程，我们的　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…61


…………………………………………………………Page　66……………………………………………………………

第　5　章　　失败的过程也是过程　　



目标，都是要“实现”它。　　



　　　　　　



　　　　工程只是一种实现的途径。最初做开发的前辈们，不　



用什么工程或者过程，也一样编出了程序，也一样解决了　



问题，也一样实现了目的。而现如今，我们讲工程了，讲　



过程了，讲方法了，却什么都再也做不出来了。　　



　　　　不奇怪么？　　



　　　　　　



　　　　工程被当成了借口，掩盖了我们做事的真正目的：“实　



现”。因此，我们在一个项目中常常听到说“工程要这样　



做”，或者“工程要那样做”，而绝少听到“项目要求这样　



做”或者“客户的本意是那样的”。　　



　　　　这样的结果是：我们做完了工程（　的每一个过程）　，却　



没有完成项目（　的每一个“实现目标”）　。　　



　　　　　　



　　　　为工程而工程的人，都迷失在项目中了。就象开发人　



员迷失在一个技术的细节上一样。专注于　RUP　或者　RAD　



之间的区别的人，可以把每一个过程的流程图都画出来，　



却也被这每一个流程给捆绑得死死的，再也没有挣扎一下　



的力气。　　



　　　4。　　　过程不是死模型　　



　　　　试着跳出大师们的身影，再仔细地看一下那些所谓的　



　“经典”过程，不过是在瀑布模型上的一再变形。瀑布模　



型描述了开发的主要环节，于是一群人把这些环节拧来扭　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…62


…………………………………………………………Page　67……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



去或者反复迭加，就成了　RAD　、螺旋、RUP　，以及未知　



的、还没有被扭出来或者堆叠出来的　X　、Y　、Z　。　　



　　　　　　　



　　　　　2002　　年前后，我在　CSDN　　论坛中看到一个漂洋过海　



东渡扶桑的取经人，贴出了一个被称为“日本　IT　　工业发　



展史的活字典”牛人指点的，足以令人震聋发馈的“V　字　



型模型”。　　



　　　　　这个模型是这样：　　



要求定义　　　　　　　………………》　　　　　　　运用测试（验收测试）　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　/　　

　　系统设计　　　　　………………》　　　　　系统测试　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　/　　

　　　　机能设计　　　………………》　　　　结合测试（集成测试）　　

　　　　　　　　　　　　　　　　　　　　　　　　　　/　　

　　　　　　详细设计　………………》　　单体测试（单元测试）　　

　　　　　　　　　　　　　　　　　　　　　　　　/　　

　　　　　　　　　　　　　　　CODING　　

　　　　　　　



　　　　　我看后就很不以为然。　　



　　　　　为什么呢？你看，你把　V　　　　　　　　　　　　　　　　　模型拉直了，还不就是瀑　



布模型吗？　　



要求定义　　

　　　　　

　　系统设计　　

　　　　　　

　　　机能设计　　

　　　　　　　

　　　　　详细设计　　

　　　　　　　　　

　　　　　　　CODING　　

　　　　　　　　　　　

　　　　　　　　　　测试　　

　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…63


…………………………………………………………Page　68……………………………………………………………

第　5　章　　失败的过程也是过程　　



　　　如果仅仅是这样看问题，那还只是知其表理。　　



　　　　《韩非子·外储说左上》记载了“买椟还珠”的故事：　



　“楚人有卖其珠于郑者，为木兰之柜，熏以桂椒，缀以珠　



玉，饰以玫瑰，辑以羽翠。郑人买其椟而还其珠。”　　



　　　郑人就只看到了事物的表面，而忽略了实质的东西。　



如果我们只是把　V　　　　模型当成折弯了的瀑布，那便是犯了　



相同的错误。　　



　　　因此，我们应该去思考由瀑布模型到　V　　　　　　　　模型这种变　



化的真实意图。　　



　　　　　



　　　V　模型在每一个环节中都强调了测试（并提供了测试　



的依据）　，同时又在每一个环节都对实现者和测试者的分　



离。由于测试者相对于实现者是一种监督、考察和评审的　



关系，因此它相当于在不断地做回顾和确认。　　



　　　这有什么意义呢？你把它放在一个工程外包的背景　



里去考虑就明白了。由于日本近年来老龄化严重，因此劳　



动力短缺导致的劳工输入和项目外包，直接影了它的组织　



管理模式。无论是在本国雇佣外来劳工，还是将项目直接　



外包给国外的开发团队，项目成果的阶段性考察都是他们　



的第一要务，这直接决定了何时、如何，以及由谁来进入　



下一个环节。　　



　　　因此　V　模型变得比其它模型更为实用。模型的左端　



是外包给的团队或者公司，而右端则是日本软件企业中有　



丰富经验的工程人员。这样既节省人力，又可以保障工程　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…64


…………………………………………………………Page　69……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



质量。事实上，即使左端外包方是由多个团队同时承接，　



右边的工程人员也不需要更多的投入。　　



　　　　　



　　　相对于瀑布模型，V　模型有改变了什么吗？是的。源　



于实际的需要，它把测试（和评审）　阶段抽取出来，于是就　



成了　V　模型。　　



　　　那么，如果需要，为什么不能把瀑布模型变成　W　　模　



型，或者　M　　　　模型呢？为什么就一定要跟随那个以迭代为　



基础的　RUP　模型呢？　　



　　　更进一步想，如果瀑布可以变成　V　、W　　　　　　　　　　　和　M　，为什　



么它不能更关注于其中某个具体的环节（例如实现和设计　



环节）　？如果在这些环节上引入　RUP　　的思想，哈哈，你看　



看，是不是出现了勋章模型和烟斗模型？　　



　　　　　



　　　然而你要知道，过程模型是在既有工程中总结出来　



的。也就是说，在某个模型有了名字之前就它已经存在了，　



就已经被一些团队或者公司创生并使用了。　　



　　　那么，为什么我们不是创生那些新的工程方法和软件　



过程理论的团队或者公司呢？　　



　　　5。　　“刻鹄类鹜”与“画虎类狗”　　



　　　东汉时期，伏波将军马援在南征交趾期间写过一封著　



名的家书，是教导两个“喜讥议而通轻侠客”的侄儿的，　



希望他们学习敦厚谨慎的龙伯高，不要仿效豪侠仗义的杜　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…65


…………………………………………………………Page　70……………………………………………………………

第　5　章　　失败的过程也是过程　　



季良。　　



　　　龙伯高时任越骑司马，杜季良时任山都长，都是马援　



所“爱之重之”的人。然而马援告诫两个侄儿说：“效伯　



高不得，犹为谨敕之士，所谓刻鹄不成尚类鹜者也。效季　



良不得，陷为天下轻薄子，所谓画虎不成反类狗者也。”　　



　　　于是，伯高、季良因马援家书而名留史册，“刻鹄类　



鹜”和“画虎类犬”就此成为典故。这意思便是说，雕刻　



天鹅不成，总还可以像只鸭子（鹜）　；若画虎不成反而像条　



狗，那就事与愿违，贻人笑柄了。　　

　　　　　

　　　后来的后来，近代作家朱湘就引用了这个典故，写了　



一篇《画虎》并收入《中书集》。《画虎》中说“一班胆小　



如鼠的老前辈便是这样警劝后生：学老杜罢，千万不要学　



李太白。因为老杜学不成，你至少还有个架子；学不成李　



的时候，你简直一无所有。这学的风气一盛，李杜便从此　



不再出现于中国诗坛之上了。所有的只是一些杜的架子，　



或一些李的架子。”　　



　　　　　



　　　　《画虎》这篇文章真的是好，真是建议大家读读。其　



中画师与画匠之论，精妙深彻，痛指骨质。而后论及日本，　



　“国家中的画匠”几个字便打发了。　　



　　　大师的眼光果然独到。　　



　　　　　



　　　然而朱老先生反驳马援所说的“刻鹄强于画虎”，却　



实在显得牵强。他说“鹜真强似狗吗？试问它们两个当中，　



是谁怕谁？”，又从“聪明”、“警醒”两个角度来说明狗　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…66


…………………………………………………………Page　71……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



强于鹜。我就觉得奇怪了，这与刻鹄之“刻”、画虎之“画”　



有什么关系呢？　　



　　　　　　



　　　　马援说刻成鸭子比画成狗好，其真实的意思是说学龙　



伯高不成，可得“谨敕”；学杜季良不成，则会流于“轻　



薄”。马援比较的是二者在骨子里所得所失的东西，而不　



是架子上的象与不象。　　



　　　　同样，以得失而论，在瀑布模型与　RUP　　模型之间，　



学习前者而不成，可思过程的本质；学习后者而不成，可　



得文字的架子。——用　RUP　　用不好的人，总会说自己终　



归还有一堆文档模板可以抄，便是这个缘故。　　



　　　　过程理论中，如果懂得了所谓的模型原本都演化自那　



个简单的瀑布，那么文档是按　XP　　　　　　　　　　　　写还是按　RUP　　写，也　



就可以应时、应需，因地置宜，择善而从了。——本质的　



东西若能理解得透，架子还不是随手搬来就可以用的吗？　　



　　　　越是简单的东西，往往越是接近于本质。　　



　　　　　　



　　　　RUP　　中，真正精髓的东西，既不是那个　R（Rational）　，　



那是人家的招牌；也不是那个　U（Unified）　，那是人家的广　



告。而是那个　P（Process）　，那才是实实在在的东西。你要　



明白，如果瀑布模型理论是　Rational　提出的，他们一样会　



把它叫　RUP　。　　



　　　　　　



　　　　朱湘说：“画不成的老虎，真像狗；刻不成的鸿鹄，　



真像鹜吗？不然，不然。成功了便是虎同鹄，不成功时便　



都是怪物。”　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…67


…………………………………………………………Page　72……………………………………………………………

第　5　章　　失败的过程也是过程　　



　　　　马援说：“学龙伯高，即使达不到他的水平，总还能　



成为一个谨慎的人；而学杜季良如果学不到家，便会沦为　



轻薄浪子。”　　



　　　　　　



　　　　你到底是选择架子？还是骨子？　　



　　　　6。　　　工程不是做的，是组织的　　



　　　　我们总是在说“做工程”，好象工程就是面包馒头一　



样，有个模子，拿来照着一堆面按上一按，放在笼屉上蒸　



上一蒸，就可以“做”出来了。　　



　　　　　　



　　　　经历过工程的人都知道，我们没有那个模子，而工程　



中的人员也不是那一堆面。　　



　　　　所以我们当然不能“做”工程，而是要“组织”工程。　



项目经理的工作，就是要去组织这个工程中的各个角色，　



使得分工明确，步调一致，共同地完成这个项目。　　



　　　　　　

　　　　　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…68


…………………………………………………………Page　73……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　



　　　　　　　　　第6章　　从编程到工程　　



　　　　　“得其精而忘其粗，在其内而忘其外；见其所见，不　



见其所不见，视其所视，而遗其所不视。”　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《列子·说符》　　



　　　　1。　　　语言只是工具　　



　　　　我曾经是非常执着的开发人员。我有连续几天几夜做　



Coding　的经历，也曾经为了一个技术问题耗上三、四个　



星期而导致项目一再延迟，还曾经为了一个实现细节与项　



目相关的人员逐一争论。　　



　　　　我也曾经象大多数的开发人员一样热衷于争论语言　



之间孰优孰劣。我在“Delphi　大富翁论坛”上写过一个简　



介，其中个人特长是“长　TPascal　、Delphi　、TASM　系列语　



言，痛恨　C/C＋＋　。（凡见有价值之　C　　代码，先读通，后写　



成　Pascal/Delphi　，最后骂一句：C　写得真笨！）　”。我至今　



保留这段文字，因为那的确是真实的经历。　　



　　　　　　



　　　　如今我已经不再专注于语言，正如我在第一章中写到　



的一样：成天讨论这门语言好，或者那门语言坏的人，甚　



至是可悲的。　　



　　　　然而就　在　我写这　段　文字之　前　的一年　，　我还在　写　



　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…69


…………………………………………………………Page　74……………………………………………………………

第　6　章　　从编程到工程　　



　《Delphi　源代码分析》，我还是无尽止地深入语言的细节，　



深入操作系统的细节，以及深入……开发的细节。　　



　　　　　　



　　　　就在　2004　　年　3　　月间，我接受一个朋友的邀请，去北　



京做一个名为“Delphi　&　Delphi　　源码分析”的专题　



培训。我用了近两周的时间，做了　50　　页的幻灯，全面讲