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

　　4)工匠、工艺隐喻

　　说到工程隐喻，现在大家自然会想到最近出来的《软件工艺》这本书。如果工程的隐喻有问题，那么工艺怎么样？如果工程师的隐喻有问题，那么工匠怎么样？按照软件工艺的说法：“如果项目中的成员不具备执行项目过程所必备的技能，那么纵有世界上最好的过程，也无法挽救项目失败的命运；与此相反，真正优秀的开发者，能够让任何过程，发挥最大的作用。”真的就这么简单吗？

　　工匠与工艺的隐喻，与工程相对，但是这样的对立，并非如《软件工艺》所理解的那样，是由于不同的复杂程度而做出的不同的选择。如果2000个人年的项目，我们应该采用工程的隐喻，5个人年的项目，我们应该采用工艺的隐喻，那么50个人年呢？500个人年呢？我们是不是有可能将两种不同的隐喻像调鸡尾酒一样，选取适合的比例，然后调制起来呢？这样具有的“颠覆性”的理论，我想作者也没有考虑过如何与工程隐喻相调和吧？

 

　　在工艺隐喻中，还有几个特点，质量、培训、高手。

　　工艺隐喻，意味着工匠（程序员）会在自己的作品上签名，并终生为之负责（这与XP是有区别的）这样就能保证质量。但是我们知道，手工制作就意味着质量无法保证，第一次与第二次不同，第二次与第三次不同，现代工业比起手工业来最大的进步，就是能够保证一个始终如一的质量水平。所谓为自己的作品负责的荣誉感，最多只能保证我能够在“事发之后”找到人来修补，却不能保证我免受这样的损失。软件质量更多的取决于一个开发团队的能力，而不是他们愿意为之负责的决心与荣誉感。如果真的那么简单，中国男足立了那么多次军令状了？早就该有成效了吧？

 

　　培训开发人员，当然是非常重要的，但是现在软件开发中较多使用的“新手”，并非“工程隐喻”的罪过。作者设想的学徒的过程，也并不与软件工程相矛盾，这在日本的软件工程实践中，可以得到证实。不客气的说，这样的浮躁，不是软件工程的责任，而是文化的问题。可悲的是，中国的软件产业，较之美国，更为浮躁。

 

　　高手是宝贵的，但同样也是稀缺的。一个公司或者一个项目团队，不可能全由高手组成，再者，对于一个项目来说，所有的活都让高手来干，也同样是浪费。在这里还要指出作者的自相矛盾之处。一方面，作者强调“师—徒”式的培训，另一方面，又想把低手从公司里赶出去。那么究竟该怎么做呢？如果一个项目内，低手比高手还要多（这是几乎是必然的）。这样的项目应该如何组织呢？任务如何划分呢？作者没有告诉我们。因为在工艺里面，学徒做的可能是毫不重要的，甚至是重复的劳动，只是为了学习。但是在软件企业，谁来为这样的学徒买单呢？

 

　　工艺的隐喻，新则新已，好就未必。这本书，就是那种“用隐喻来思考的产物”。真要照做，只怕危险。

 

　　5)敏捷的场景

 

　　敏捷开发与其它模式不同，它似乎没有隐喻，但是，还记得我们是如何定义隐喻的吗？一个隐喻是一个完整的场景，这个场景中有很多相互交织的“概念要素”。 当这个场景中多出了与软件开发无关的要素时，就会误导我们。敏捷开发是一个逼真的场景，这个场景不是像软件开发，它就是软件开发，它没有多出任何东西，因此，这样就完美了吗？不，它却少了很多要素。当一个逼真的场景，向你描述了一个成功的，但是却却少了很多要素的软件开发项目时，这样的场景同样会产生误导，会使你认为其他的要素，都是不重要的，至少是可以在大型项目中才需要考虑的。我说的要素，并非CMM的KPA，或者RUP里的关键活动，然后通过剪裁就能得到XP那样的要素。而是指关键的概念，缺少关键概念，故事就会显得虚假，那么在敏捷项目中，缺少了什么呢？时间概念，成本概念以及分工概念。

 

　　在一个又一个的迭代周期中，什么时候，项目算是完成呢？这个完成，由谁来决定呢？似乎敏捷开发面对的是一个User Story集合，多一些，少一些，都没关系的。如果用户给定时间，功能的多少，就得由开发人员决定。反之，如果用户要求必须数量的功能，开发时间的多少就得由开发人员决定。这样的项目，可以说简直没有压力，这是咱们梦寐以求的项目，但是这可能吗？

 

　　再说成本概念，同样的道理，合同是在开发开始之前签订的，但是按照敏捷开发的场景，能开发出多少东西，需要多少时间，都是不一定的。那么成本如何确定？如果成本无法确定，这个合同可能就会有一方要吃亏，这样的合同，谁去签呢？

 

　　再说分工概念，敏捷开发是程序员提出的，而且完全是从程序员的角色出发，在他们的故事里，除了用户，就只剩下了程序员，你也许会说，还有项目经理呢！但是，那只不过是一个名称而已，他不过就是一堆程序员里最有权威的那个。那么其他角色呢？你在敏捷开发的故事里，看不到界面设计人员，看不到独立的、专职的测试人员，看不到数据库管理人员（随着设计的浮现，也许项目进行到40%时，程序员中会有一个人，转而承担较多的数据库管理的职责，但是这并不一定）看不到产品经理，看不到用户手册的编写人员，看不到客户培训人员（XP认为客户会和程序员一起工作，但是那些没来的可能谁去培训呢？）也许XP的支持者会说，“嗨，我们又不是要开发巨型项目。”但是我要说的是：“不管有多大的项目，一定会有不需要、也不应该程序员做的事情。”作为一个软件开发的方法论，就必须包含对这些工作的探讨，一个完全从程序员本位出发的，不考虑其他工作的方法论，不是一个完整的方法论，这样的场景如果被普遍模仿的话，也是相当危险的。

 

　　6)银弹隐喻

 

　　《没有银弹》如此著名，以至于无论它的赞同者还是反对者，都无法回避它的存在。但是银弹究竟是什么呢？“没有银弹”究竟意味着什么呢？

 

　　首先，“银弹”是一个隐喻，它的本意是能够杀死人狼（一种怪兽）的武器。用在软件开发里，银弹是什么，用通过追问“什么是软件开发中的人狼”来得到答案。在一个项目中（在一个村庄里），出现了一个困难（出现了一头人狼），如果任由困难存在，项目就会失败（如果没有办法赶走人狼，村民就会受害），一种方法出现了，解决了这个困难，项目成功了（银弹出现了，打死了人狼，村民获救了）。所以我们可以这样理解：银弹就是能够保证项目成功的方法。但是，如果Brooks真的这样简单的推出自己的结论，那么大家都会说；“废话，谁不知道，没有一种方法能够保证项目的成功？”Brooks的水平当然远不止此。但是很多人对《没有银弹》的理解，却事实上到此为止了，然后他们就拿着这个结论，四处“传道”开来。

 

　　Brooks更进了一步（或者说退了一步），他将保证项目成功的目的，弱化为提高项目效率的目的，并且给出了一个看起来能够量化的标准“单一技术，十年之内，提高十倍以上的效率。”（可靠性和简洁性根本无法量化，咱们先不讨论）

 

　　但是，我们知道，如果一个论断无法证实，又无法证伪，这个论断就毫无意义。那么我们如何能够检验他的这个论断呢？首先我们要能够明确，什么是单一技术？软件工程算单一技术吗？CMM体系算吗？CMM里的一个KPA呢？UML算吗？设计模式呢？XP呢？还是XP中的结对编程呢？怎么才算单一？没有界定！也无法界定，包括Brooks，也不能告诉我们，什么算单一技术？

 

　　然后我们还要确定，如何比较开发效率，如何量化？严格的说，必须证实两组能力，知识水平，人数，了解的信息都完全相同的人马，在互不交流的情况下，同时开发一个项目，都达到了一组项目的目标（即不是不够，也不是超过），然后两组人的开发时间，是否相差十倍。

 

　　再者，当我们要证明单一技术的功效时，必须保证这两组人马只在这一项技术上有区别，其他都一样。

 

　　最后，当我们要证明十年之内的差别时，还要保证十年后的这组人马，与十年前的那组人马使用相同的软件、硬件设备。（十年前是什么操作系统？WIN32？CPU呢？486？）这样的研究，才能够算是精确的验证。但是这样的验证，没有，也不可能有人去进行，自然这样的论断也就毫无意义！

 

　　可笑的是，居然有人，当真去寻找银弹的证据，并且兴奋的宣称找到了，最近还有一家著名的公司，出版了一本的著名的杂志，名字就叫《银弹》！但是，最可笑的还在于，Brooks居然还写了一篇《再论没有银弹》，宣称自己的论断，已经基本上成立了。

 

　　如果事情到此为止，那么Brooks也不过就是跟大家开了个玩笑罢了。但是Brooks更进一步指出：“软件开发分为根本问题与次要问题，根本问题占软件开发的90%的比重。而且很难被很好的解决。”一方面，我们要说：“这样的认识很有必要”，另一方面，我们也要说：“这样的论断，毫无疑义。”因为它既不能被证实，又不能被证伪。90%从何而来？如何证实？我们无法得知。我相信，10年，10倍，根本就是他随口说出的一个数字，同样的，90%也不过是一个“印象”。当不得真，作不得数，也无法用来指导我们的实践，更无益于我们提高软件开发水平。这样的玩笑文字，竟然风行世界，备受瞩目，的确是软件开发的方法论，还处于蒙昧的“隐喻时代”的最好证明！

 

(未完待续)