定论——软件开发的方法-论探讨(6) 软件测试编程音乐项目管理设计模式

三、软件开发的特征

 

　　软件开发究竟是怎么一回事呢？在我的前一个连载《敲响OO时代的丧钟》里，我也讨论到了软件开发的实质，自己引一段来用用。 

软件开发的定义：“软件开发，就是在一个受到限制的环境中，利用环境提供的可能性，修改或添加环境允许的各种状态，去满足某一组需求。”

1) 软件开发所处的环境，不仅仅是一个限制，同时也是一个可能性。软件的能力，局限性与硬件的能力，比如说，如果计算机没有喇叭，那么任何软件都不能使计算机播放音乐。但是，另一个必须考虑的方面是，同样有能力发声的计算机，要想使他播放音乐，可能很容易，也可能很困难。用专业一点话来描述就是：“有些硬件的API设计很合理，有些则非常愚蠢。”由于我们对于软、硬件的定义是一个连续体，因此，这个观点不只是可以用来评价硬件API设计，也可以用来评价语言、虚拟机、框架、平台等等软件的一个方面的优缺点——是否有利于二次开发，这是一个重要的评价标准。

2) 修改、添加状态，比较拗口，其实就是编程的意思。在一个受限制的范围内编程，我们需要考虑很多东西，语法、接口、规范、内存大小诸如此类，当然，不同级别的，不同领域的编程，需要考虑的限制是有巨大差别的。软件开发的水平高低也就体现在，满足同样的需求，有些方法速度更快，有些方面却要慢很多。而软件开发的方法的选择，受到很多因素的影响：环境限制，经验多少以及对于需求的了解程度等等。

3) 满足需求，是啊！提起这个需求，每一个程序员都会有好多的苦水要倒出来。为什么满足需求就这么难呢？因为，对于程序员来说，那是另外一个世界(这是比较客气的说法)，那些提需求的家伙根本不懂怎么说话(这个说法稍为激烈一些)，那是一些不知道自己要什么的蠢货(你遇到过这样的用户吗？)作为程序员，我知道我有很多同行，非常苦恼于与客户谈需求这样的任务——“至少电脑不会出现前后矛盾的逻辑错误”——这就是做程序员的难处。如果我们不仅仅是抱怨的话，也必须承认，程序员是非常挑战的职业，一个好的程序员，不但得是软件开发领域的专家，还得是他开发的那一类软件所在领域的专家。但事实上，其他行业的人，只需要做一种专家就能够混得很好了。

　　软件开发的实质，与软件开发的特征之间，还是有区别的。毕竟我的前一篇文章，是从技术的角度出发来看软件开发，而现在我们的要讨论的是从管理的角度来看待，它又有哪些特征呢？

　　软件开发的管理特征，在外行看来，也就是一堆人在做个东西。但是，软件开发的独特之处就在于，软件开发是由一堆独特的人，以独特的方式，做独特的东西。我们先来看看软件开发，遇到了哪些独特的困难：

 

　　1、沟通困难：同为软件开发，可能面对的思维模式，是完全不同的世界。比如二进制的世界，函数的世界、逻辑的世界、过程的世界、对象的世界、二维表的世界等等等等。在这些不同的世界中开发软件，需要的思考方式、思维习惯都是不同的。开发项目大到一定程度以后，不同的世界必须在一个完整的项目中和谐并存，这些差异，有时候就会带来沟通障碍。再加上技术与需求世界之间的差异，沟通成为一个非常重要的工作。软件开发中的人与事，如何才能有效沟通，是一个非常重大的课题。

　　2、控制困难：程序员都是些怪人，至少都是些聪明人。要让他们听话，很难啊。一个项目，要想顺利进行，程序员们能够接受的，必须是“稳定而合理的命令”。而在软件开发过程中，往往需求频繁变动，领导层层叠叠，用户花样百出，计划一改再改。程序员们经常会接到朝令夕改的命令，而且还来自于那些莫名其妙，连说话的逻辑都成问题的家伙。如何才能知道，那些小伙子是在严格地执行命令而不是在那里磨洋工呢？

　　3、评价困难：要控制，必须要能够赏善罚恶，但是在软件开发中，何为善？何为恶？如何评价一个程序员的工作？我们当然可以在项目计划该结束的时候，再去问他们，做完了吗？但是如果他们那时候没有完成，再要挽救就来不及了。必须在项目开发过程中建立即使有效的反馈机制。以小而高密度的评价手段，来对开发过程进行较为准确的控制，这一切，都必须建立在合理的评价机制的基础上。但是，这样一套评价机制，非常困难。什么才算是好的需求分析？好的代码？好的设计？好的测试用例？没有定论。举个例子：两三年前，在项目中加入EJB的成分，越多越好。现在呢？设计人员，随时都可能被人指责滥用EJB。这风向变得也太快了。

　　4、估算困难：这个在上一章我们也讨论到了，软件开发与其它行业的一个重大区别，就在于对于软件开发的估算成本，不能忽略不计。想要估算变动剧烈的项目的时间、人力、成本，简直就是不可能的任务。

 

　　怎么办？

 

(未完待续)