做软件工程不是做过程

文：鼎捷ERP

作者：鼎捷数智 | 发布时间：2012-11-30 14:50:34

第一节做过程不是做工程
    软件工程这个概念被提出的时候大概是在上个世纪60年代末。它作为成熟的概念的标志是软件工程的瀑布模型的提出。瀑布模型将软件开发的过程分成需求、分析、设计、开发和测试5个主要阶段，其主要环节关系表现为如下的这样一种形态：
    在瀑布模型之后，很多人开始研究过程模型的问题。很多从实际工程中提炼出来的过程模型都是值得称道的，例如RAD(RapidApplicationDevelopment，快速应用开发)模型、螺旋模型和现在常被提及的RUP(Rational UnifiedProcess，Rational统一开发过程)模型。
    模型就是‘‘样子”。人家拿出一个东西来说：这是模型。其言下之意就是要你按照这个样子来做。过程被描述为可重复的模型，实施的结果却可能演变成为如下面这张图所展示的尴尬局面：
我们看到，按照模型所描述的这个“样子”，做完过程的每一个阶段，并不等于做完了工程。或者说，工程并不是这样就可以做成功的。
换而言之，无论是用RAD模型还是RUP模型来做工程，即使是亦步亦趋，也做不好工程。
如果工程可以那样做成的话，只需要有瀑布模型就足够了。因此“做过程”并不是做工程的精义。
    也不是目的。
    前面那张图就是一个过场。尽管那是一张用来描述“沟通问题”的经典图例，然而你应该注意到，每一个角色都把自己的环节当成一个“过场”。如同演戏一样，从A做到Z，就一切都完成了。当然，按照RUP的思想，是要从A到Z一遍又一遍地做下去的。然而，如果每一遍(或者用RUP的那个术语“迭代’’)都只是‘‘过场”的话，项目将只是一场无休止的演出而已。
    较终呢?观众受不了了，就交钱走人；演员受不了了，就下台散伙。戏目和项目的结局，竟如此地相似。

第三节实现，才是目的
    很多人把问题的本质给忘掉了。从较开始，从我们编程开始，我们的目的就是实现一个东西。无论这个东西是小到称手的一个工具，还是大到千万的一个工程，我们的目标，都是要“实现”它。
    工程只是一种实现的途径。较初做开发的前辈们，不用什么工程或者过程，也一样编出了程序，也一样解决了问题，也一样实现了目的。而现如今，我们讲工程了，讲过程了，讲方法了，却什么都再也做不出来了。
    不奇怪么?
    工程被当成了借口，掩盖了我们做事的真正目的： “实现”。因此，我们在一个项目中常常听到说“工程要这样做”，或者“工程要那样做”，而绝少听到“项目要求这样做”或者“客户的本意是那样的”。
    这样的结果是：我们做完了工程(的每一个过程)，却没有完成项目(的每一个“实现目标”)。
    为工程而工程的人，都迷失在项目中了。就像开发人员迷失在一个技术的细节上一样。专注于RUP或者RAD之间区别的人，可以把每一个过程的流程图都画出来，却也被这每一个流程给捆绑得死死的，再也没有挣扎一下的力气。
第四节过程不是死模型
试着跳出大师们的身影，再仔细地看一下那些所谓的“经典”过程，不过是瀑布模型的一再变形。瀑布模型描述了开发的主要环节，于是一群人把这些环节拧来扭去或者反复迭加，就成了RAD、螺旋、RUP，以及未知的、还没有陂扭出来或者堆叠出来的X、Y、Z。
2002年前后，我在CSDN论坛中看到一个漂洋过海东渡扶桑的取经人，领受了被称为“日本IT工业发展史的活字典”的某个牛人的指点，贴出了一个足以令人振聋发聩的“V字型模型”。
这个模型是这样：
我看后就很不以为然。
为什么呢?你看，你把V模型拉直了，还不就是瀑布模型吗?
    然而如果仅仅是这样看问题，那还只不过是知其表理。
    《韩非子外储说左上》记载了“买椟还珠”的故事： “楚人有卖其珠于郑者，为木兰之柜，熏以桂椒，缀以珠玉，饰以玫瑰，辑以羽翠。郑人买其椟而还其珠。”
    郑人就只看到了事物的表面，而忽略了实质的东西。如果我们只是把V模型当成折弯了的瀑布，那便是犯了相同的错误。
    因此，我们应该去思考由瀑布模型到V模型这种变化的真实意图。
    V模型在每一个环节中都强调了测试(并提供了测试的依据)，同时又在每一个环节都做到了对实现者和测试者的分离。由于测试者相对于实现者的关系，是监督、考察和评审，因此测试者相当于在不断地做回顾和确认。
    这有什么意义呢?你把它放在一个电子商务工程外包的背景里去考虑就明白了。由于日本近年来老龄化严重，因此劳动力短缺导致的劳工输入和项目外包，直接影响了它的组织管理模式。无论是在本国雇佣外来劳工，还是将项目直接外包给国外的开发团队，项目成果的阶段性考察都是他们的第一要务，这直接决定了何时、如何，以及由谁来进入下一个环节。
    因此V模型变得比其他模型更为实用。模型的左端是接受外包任务的团队或者公司，而右端则是日本软件企业中有丰富经验的工程人员。这样既节省人力，又可以保障工程质量。事实上，即使左端的夕I、包任务是由多个团队同时承接，右边的工程人员也不需要更多的投入。
    相对于瀑布模型，V模型有改变了什么吗?是的。源于实际的需要，它把测试(和评审)阶段抽取出来，于是就成了V模型。
    那么，如果需要，为什么不能把瀑布模型变成W模型，或者M模型呢?为什么就一定要跟随那个以迭代为基础的RUP模型呢?
    更进一步想，如果瀑布可以变成V、W和M，为什么它不能更关注于其中某个具体的环节(例如实现和设计环节)?如果在这些环节上引入RUP的思想，哈哈，你看看，是不是出现了勋章模型和烟斗模型?
    然而你要知道，过程模型是在既有工程中总结出来的。也就是说，在某个模型有名字之前它就已经存在了，就已经被一些团队或者公司创生并使用了。
    那么，为什么我们不是创生那些新的工程方法和工作流软件过程理论的团队或者公司呢?

第五节 “刻鹄类鹜”与“画虎类狗”
    东汉时期，伏波将军马援在南征交趾期间写过一封著名的家书，是教导两个“喜讥议，而通轻侠客”的侄儿的，希望他们学习敦厚谨慎的龙伯高，不要仿效豪侠仗义的杜季良。
    龙伯高时任山都长，杜季良时任越骑司马，都是马援所“爱之重之”的人。然而马援告诫两个侄儿说： “效伯高不得，犹为谨敕之士，所谓刻鹄不成尚类鹜者也。效季良不得，陷为天下轻薄子，所谓画虎不成反类狗者也。”于是，伯高、季良因马援家书而名留史册， “刻鹄类鹜”和“画虎类犬”就此成为典故。这意思便是说，雕刻天鹅不成，总还可以像只鸭子(鹜)；若画虎不成反而像条狗，那就事与愿违，贻人笑柄了。
    后来的后来，近代作家朱湘就引用了这个典故，写了一篇《画虎》并收入《中书集》。《画虎》中说“一班胆小如鼠的老前辈便是这样警劝后生：学老杜罢，千万不要学李太白。因为老杜学不成，你至少还有个架子；学不成李的时候，你简直一无所有了。这学的风气一蛊，李杜便再出现于中国诗坛之上了。所有的只是一些杜的架子，或一些李的架子。”
    《画虎》这篇文章真的是好，真是建议大家读读。其中画师与画匠之论，精妙深彻，痛指骨质。而后论及日本， “国家中的画匠”几个字便打发了。
    大师的眼光果然独到。
    然而朱老先生反驳马援所说的‘‘刻鹄强于画虎”，却实在显得牵强。他说‘‘骛真强似狗吗?试问它们两个当中，是谁怕谁?”，又从“聪明”、 “警醒”两个角度来说明狗强于鹜。我就觉得奇怪了，这与刻鹄之“刻”、画虎之“画”有什么关系呢?
    马援说刻成鸭子比画成狗好，其真实的意思是说学龙伯高不成，可得“谨敕”；学杜季良不成，则会流于‘‘轻薄”。马援比较的是二者在骨子里所得所失的东西，而不是架子上的像与不像。
    同样，以得失而论，在瀑布模型与RUP模型之间，学习前者而不成，司思过程的本质；学习后者而不成，可得文字的架子。——用不好RUP的人，总会说自己终归还有一堆文档模板可以抄，便是这个缘故。
    过程理论中，如果懂得了所谓的模型原本都演化自那个简单的瀑布，那么文档是按XP写还是按RUP写，也就可以应时、应需、因地置宜、择善而从了。本质的东西若能理解得透，架子还不是随手搬来就可以用的吗?
    越是简单的东西，往往越是接近于本质。
    RUP中，真正精髓的东西，既不是那个R(Rational)，那是人家的招牌；也不是那个u(Unified)，那是人家的广告。而是那个P(Process)，那才是&