过程塑造: （三）代码是最终目的

意图
无论哪一种过程，其最终目的都是为了产生出可执行、并且可用的软件。因此软件过程中的各种活动应该围绕着快速、准确的实现这一目的而展开的。

示例
维力亚软件公司是一家合资公司，由于有外资背景，公司内部很早就引入了软件工程，并严格的对人员角色进行分工。包括领域建模人员、架构设计师、高级程序员、程序员、界面设计师等等多种角色。每个人各司其职，充分发挥出了分工的特点。但是随着公司开发项目的逐渐增多，这种方式也显露出其弊端来。每个人的主要目标都是为了通过评审，而有时候，就算是通过评审的工件，依然可能存在问题。但这时候扯皮就出现了。项目中存在的一些中空地带。以及交错地带，常常发生无人问津的情况。开发过程的效率开始下降，开发成本开始上升。问题虽然不是一下子出现的，但是已经逐渐变得严重起来了。

上下文
我们在进行过程设计，或引入一个过程理论的时候，有没有思考过该过程的每一个阶段、每一个活动的目的是什么，它们对生成最后的软件有什么样的帮助，这些帮助对于我们所在的组织有意义吗。很多情况下，我们并没有这么做，或者随着软件过程的定型，就不再思考这类的问题。一开始并没有什么了不起的，但是当软件过程演变成了一种政治体系的时候，那么问题就会慢慢严重起来。

问题
如何让过程围绕着产出软件的核心目标而不断演进？

方法
从上一篇介绍的内容中，我们知道软件过程的每一个阶段都是知识转换的过程，知识转换的终点就是软件。问题在于，我们如何保证这种转换的效率呢？

现代软件的发展的趋势是重用。我们开发一个软件已经很少会从最底层开始编写了。我们使用各种各样的技术和平台。包括数据库、分布式体系、UI机制、业务元素等等。因此现在的软件编写往往都是站在巨人的肩膀上开始的。不同的软件组织，肩膀的高低也不一样。比如有的软件组织使用J2EE平台，有的软件组织则使用.NET平台。但是可以肯定的一点是，每个软件组织都或多或少的拥有自己的平台体系开发经验。这些经验的表现形式也不尽相同，可能是保存在某些高级技术人员的脑中，也可能是保存为文档、模型或代码的形式。

对于单个的项目而言，其过程一定是从需求开始，以部署（以及后续维护）为终结的。但是对于长时间存在的软件组织而言，更重要的是项目经验、技术经验、管理经验的积累。这样说可能过于抽象，我们举一个具体的例子。在完成了一个库存管理项目之后，我们把库存管理的领域知识制作为商业组件的形式，而把项目中学习到的一些编码的技巧整理为模式的形式，并把项目过程中积累的过程方法添加到现有的软件过程中。这些经验的堆积就是在一开始我们提出的可重用框架。对一个软件团队的来说，它的所有软件项目都应该是围绕着这一个可重用框架而展开的。

迄今为止，我们见过的大多数的可重用框架表现形式都可以总结为：以开发平台为基础，积累自己的商业组件，并以此为中心订立开发活动。这种形式是不是最好并没有定论，但我们是抱着学习的态度来研究它的。

以开发平台为基础的意思是软件组织必须有自己所熟悉的开发平台，其大部分的项目都是在此基础上进行的。目前最流行的两种软件开发平台是J2EE和.NET，但是就算是同一个平台，不同的软件组织对平台内部的侧重也是不同的（同样对于J2EE技术，有的软件组织可能把JSP和Servlet作为核心选择，而另一些软件组织则把重点放在EJB上）。选择一种广泛应用的、具有生命力的平台技术是非常重要的。因为你的框架将会以此为基础进行，而框架的转移成本是非常之高的。虽然我们在一开始介绍的MDA思路为我们绘制了一副平台无关设计的美好愿景，但是在目前阶段，我们仍然要面对不同软件平台造成的严重隔阂。

必须指出的是，我们上面提到的开发平台指的是在操作系统这个层次之上的平台，也就是俗称的中间件平台。但是从中间件到最终的产品之间有没有过渡的平台呢。其实可重用框架就扮演了这一角色。软件市场上已经出现了商业化的可重用框架了。IBM的SanFrancisco框架就是这种概念的代表。

平台技术仅仅只是提供了一个技术，而软件组织要生存和发展，还需要积累和发展自己的商业组件。并将商业组件发展成为可重用框架。商业组件的好坏，直接和软件组织的能力、经验，以及平台技术相关。商业组件可能直接表现为代码的形式（Bean、类、COM组件等），也可能只是描述性的记录（文档）。商业组件是经验积累而成的。请注意，商业组件的设计并不完全等同于面向对象开发，因为面向对象只是一种技术手段，但是商业组件设计的优劣，更重要的是对业务的理解程度。举一个最浅显的例子，一个精通面向对象开发、面向组件开发的设计师，让他介入他完全不了解的行业组件设计，他的表现将会大打折扣。

到目前为之，大家所认识的框架仍然是技术型的框架。但事实并非如此，框架还包括了外延的一系列软件活动。这才是一个完整的框架。结合之前我们讨论的软件交付为开发目标。我们把这种开发方式称为以可重用框架为核心，以交付为目标的软件开发。这其实并不是什么了不起的概念，大部分的软件组织都已经这么做了，只是没有意识到自己的方式而已。了解这一点，能够帮助软件组织有效的改进自身的构架。

平台技术和组件开发并不是本文的重点，因此我们在肯定了两者的重要性之后，把精力转移到软件活动上。

在拥有一个框架核心（平台和商业组件）之后，框架需要包含这样的活动（或活动集）：收集项目需求，并将需求映射到核心构架上来。这其实就是需求阶段到设计阶段要做的事情。但是由于我们的活动是以软件交付为目标的，因此我们需要明确的指出活动中的注意事项。

为映射工作设计需求描述规格。需求并不是一件容易的事。最难的莫过于尺度的把握了，例如需求要多详细。使用现成的技术来定义需求描述规格，并根据核心框架的特点进行必要的扩展。例如，我们使用成熟的用例技术来描述需求，同时我们要求需求按照不同类的商业组件进行分类索引。用例技术的推荐读物是Alistair Cockburn的Writing Effective Use Cases一书，该书目前已有英文影印版。