软件是怎么写成的？

 

开发软件的方式多种多样。有瀑布型(Waterfall model)，有渐进型(Incremental model)，有进化型(Evolution model)，有样机型(Prototyping model)，有RUP，有XP，有敏捷开发。不一而足。到底应该选用那种方法呢？

 

软件开发归根结底不外乎两方面：技术和管理。技术方面包括分析、设计、编程、调试等。管理包括人员管理、进度管理、风险管理、质量管理、文档管理、代码管理等。而上述这些方法也都是围绕这两方面，不过是各有侧重而已。

 

选择何种方法很大程度上取决于项目的特点和开发团队的状况，而不必拘泥于某一种方法。如果对项目的需求很清楚并有类似的开发经验，不妨采用瀑布型开发方式，因为最省时间。如果对需求不很清楚也没有开发类似项目的经验，可采用渐进型，或渐进型加样机型。

 

我本人一直从事软件工具的开发。每个新功能的开发基本上都是新的挑战。所以，我们用渐进型开发方式较多。

 

在确定开发一个新功能(feature)后，我们会花一些时间考虑总体设计，主要是分模块、分层，一般不会超过一、两个月。主要是弄清高层模块之间的关系，并确定重要的类。我们会画一些模块图、类图和序列图(sequence diagram)，使大家对系统有整体了解。大框架确定后，就开始写代码。我们不是每个模块每一层都分别写好后再集成，而是采用功能驱动(feature-driven)的方式开发。我们列出能想到的子功能，排出其先后次序。最重要、最基本的功能先开发。

 

在开发每个子功能时，我们只写这个子功能所必需的类、接口(interface)和方法(method)。然后马上把各模块、各层集成起来，尽快让系统动起来。这样开发组能及时对系统进行直观的评价，这样有助于尽快加深对系统的认识，也能让质量控制组尽早介入，及时提供反馈信息。

 

在开发过程中，各模块、各层的开发基本上是齐头并进的。在我们看来，软件就像是长起来的，而不是拼起来的、搭起来的。随着功能的增多，系统会越来越复杂，而我们对系统的认识也越来越深。我们会随时调整系统的设计。去掉重复的类、重复的函数，引入抽象，引入设计模式，使系统设计逐渐趋于合理。而软件本身也就像一个小树苗一样在精心呵护、修剪下成长为有用之材。

 

当然，这个过程并不简单。需要每个开发成员能自觉地不断改进设计和代码。虽然代码复查能阻止一些错误的发生，但如果开发人员不自觉，很难写出优秀的代码。

 

另外，每个模块都应有一个明确的设计理念(design philosophy)，也就是设计目标。例如，有些模块可能强调可重用性，有些强调可扩展性，有些重视性能。在调整设计时要遵循设计理念。

 

我们也重视单元测试，但并不拘泥于测试驱动开发(test-driven development)，尤其在设计方案没确定以前。在类之间的关系比较稳定后，我们开始大规模写单元测试案例(unit test case)。在除错时，尽量用单元测试案例复现所要排除的错误。这样单元测试案例就会越积累越多，从而避免类似错误的重复发生。

 

由于系统很早就能运转（尽管功能还很简单），质量控制组能及早介入，提供反馈。这是软件开发成功的关键之一。发现问题要及时解决，尤其是关系到整体设计的问题。

 

不管组员的开发能力多强，开发组一定要有一个明确的领头人（或曰架构师）。架构师要在必要时作出决断，而决断往往在综合考虑各种因素后所做的妥协。架构师即要胸怀目标又要脚踏实地。胸怀目标是有明确的设计理念，知道软件最终要做成什么样。脚踏实地是根据实际情况找出一条通向目标的、风险最小的路，要知道什么时候该做什么，做到什么程度。目标不明确，会走错方向；不脚踏实地，会走上一条崎岖曲折、充满荆棘的路。

 

软件开发是一个复杂的过程。软件业的一些先驱们一直在寻找与软件业类似的行业，以借鉴一些经验。有人认为与建筑业类似，有人认为与手工业类似。把软件看成是一个有生命的实体，让它逐渐长起来，或许也是一个不错的类比。

 

北雁

２００６年９月