定论——软件开发的方法-论探讨(2)

　　分析各种现有的隐喻：

 

　　1)工程隐喻

　　在各种隐喻中，建筑工程与软件开发的关系最为密切，这个隐喻与软件开发的相似之处最多，因此影响也最为深远。这个隐喻有四个要点：分解、分配、设计和阶段化。

　　分解是一种极为深刻的思想，将整个过程分为几个阶段，将整个任务分解为几个子任务，将系统分解为多个层次，多个模块，将需求划分为多个类型等等。这样的思路，是解决复杂问题的唯一正确的方法，一团乱麻的需求、任务、项目、设计，根本不可能成功。但是分解也意味着它最好第一次就划分正确，当任务被层层分解，变成了很多很多的子任务、模块、子模块、类的时候。你发现有一个子任务的分解有问题，修改的困难可能极为惊人，而软件开发，在第一次就划分正确的情况，几乎绝无仅有。

　　分配与分解一样，是工程隐喻所特有的，当一个需要完成的系统，已经被仔细的分解之后，分解的粒度会达到一个人能过独立完成的范围，然后根据现有的资源以及任务的前后依赖关系，合理的分配给各有不同能力和特长的人，没有这样的分配，项目同样会一片混乱，而这个隐喻还包含一种（支配关系），存在分配的人与被分配的人，层层分解的任务与层层分解的人力资源，使得整个项目成为一个严密的金字塔结构，而这样的结构，往往使得项目的应变能力与可能性，随着项目的扩大而缩小。

　　基于以上的两个要点，工程隐喻极为顺理成章的推出了这样一个结论：“必须严格的控制需求的变更，如果可能，将所有的变更都顶回去。”纯正的软件工程的思想中，任何需求的变更都是不受欢迎的。

 

　　设计极为重要，无论是对于建筑还是对于软件开发来说，都是这样。但是设计与设计不同，在建筑行业，不体现设计师理念的建筑，会被称为没有灵魂的“水泥块”。但是在软件开发里，如果开发人员老是想着往程序里加入自己的东西，会被称为过度设计。但是由于软件开发对于建筑工程的模仿，过度设计变得比比皆是。

 

　　在建筑工程中，有着极为清晰的阶段划分，分析、设计、施工、验收。最早的软件工程，就是完全模仿这样的阶段而执行的。这样的模仿，后果是严重的，因为这样的阶段不是软件开发的特征，强行套用，大多失败。随后的改进似乎总也跳不出这个思维模式，就像用无数的直线去拟合一条曲线，用N多个正方形去拼出一个圆形。比如说螺旋式开发，在一个螺旋中，还要搞出四个象限，使得软件开发的过程，不断的重走这四个阶段。但是，软件开发的过程，真的是像建筑工程一样吗？

 

　　2)流水线隐喻

　　产生式编程和MDA，是所有“银弹”承诺中，最为大胆的两种。如果有一天世界大同，万物升平，人间与天堂无异，那应该就是MDA的时代来临了。这两种思路的理论依据（如果这能称之为理论的话）何在呢？其实还是一个隐喻：流水线。当然他们不会直接用普通的流水线来做比喻，而是一种比现代工业中最为先进的柔性制造流水线还要先进的“超级无敌自定义流水线”。用户（对，就是最终用户）可以选择、定义并且画出那个“软件装配图”（UML之类的表示方法），就能直接组装出用户想要的软件。但是，这样的隐喻其实无法用于软件开发，甚至无法用于工业生产的大多数领域。在工业领域，大多数流水线 还是用来生产有限种类的产品，种类多到一定程度之后，流水线的效率根本无法体现。当然成本优势也无法体现。这还是一个零件的粒度问题，大粒度的零件组合，使得生产的可能种类减少，而小粒度的零件，又使得装配成本与效率无法体现，这样的两难，在软件开发上同样存在，而且更加严重，所以这颗子弹，不可能是“银弹”。

 

　　3)舞蹈隐喻

　　CMM本身不需要隐喻，它的理论基础来源于纯正的软件工程，所有软件工程有关的隐喻，CMM都用得上，但是CMM有它自身的特点，主要是在CMM的实施方面。我看到过一个关于CMM实施的隐喻：软件开发就像跳舞，软件过程改进就像是舞蹈编排，软件开发人员在过程改进专家的知道下，就像舞蹈演员在舞蹈编导的知道下，学习新的节奏、动作。最后开发出令消费者满意的软件产品。就像舞蹈演员为观众带来出色的表演。这样的隐喻，为一个巨大的咨询市场开辟了道路；最天才的舞蹈演员，也不能没有编导的知道，所以想要公司提高CMM等级，就必须找专家来做咨询，果然巧妙！但是这样的隐喻，却经不起推敲，舞蹈编排过程中，演员们排练的目标是达到编导的要求，如果演出的效果不好，自然由编导负责。但是软件开发过程的改进，如果也是为了博得咨询专家的满意，到时候软件开发出来不赚钱，那些专家可不会负责。他们早就赚到咨询费，走人了。关键问题在于，过程改进只能是一种手段，它本身不能成为目的，更不能想当然的认为，完美的过程就一定能带来完美的产品。舞蹈编导不是观众，没有一个编导敢保证自己的这次创作，一定能赢得观众的好评，但是为什么现在CMM专家，就敢作出这样的保证呢？当舞蹈演员在一个“三角形的舞台上”，完美的跌落的时候，谁会为这样的悲剧负责呢？

 

(未完待续)