现象系列（一）——如何解决

如果审视一下我们的系统开发，我们会发现：我们疲于应付需求的不断变更我们的文档迅速地失效、维护困难项目二期开发生产力无法提升。每当一种新的技术产生的时候，我们必须做许多重复的工作。系统永远不可能只用一种技术实现，且不跟其它系统交互。不断变更的需求同样也给我们的系统带来困难。下面我们将分析我们在软件开发过程中遇到的问题。

1 生产力和维护性问题：文档和编码脱节，导致代码可读性差

当今我们的软件开发过程是以概要设计和编码驱动的，这样( 设计工件是文档、图) 无论我们是采用增量开发还是迭代开发，或者是传统的瀑布式开发途径，文档和设计图表都是在前三个阶段中产生。我们的需求分析往往使用文本和图的方式来描述，其中的图经常采用UML 图，如用例图、类图、交互图、活动图等。这一叠厚厚的纸面文件往往给人以深刻的印象，而其中的设计工件(artifacts) 往往仅是纸件而已。当编码开始的时候，前三个阶段产生的文档和相关图片就迅速失去了它们的价值。随着编码阶段的继续进行，图片和代码之间的关联逐渐减弱甚至消失，它们不再是对代码的精确描述，或多或少地成为了无关的图片。随着时间的推移，系统不断地被修改，文档、设计图表和代码之间的距离就越来越疏远。我们仅仅是修改了代码，因为修改文档和设计图表所要花费的代价是我们无法容忍的。同时，即使我们修改了图和文档，这样的工作是否有效也值得怀疑，因为我们还会不断地修改代码？难道我们要花更多的时间去不断修改文档吗？那些接踵而至的客户需求怎么办？哪个重要？还是放弃文档比较现实吧。那我们前期还花那么长时间写详细设计干什么呢？极限编程XP(Extreme Programming) 现在迅速地流行起来，一个主要的原因就是它承认了代码是真正驱动软件开发的力量这个事实。在开发过程中，真正产出效益的阶段是编码阶段和测试阶段。

极限编程只能够解决软件开发中的部分问题 ：当一个团队初始开发一个系统的时候，保存在它们大脑中的设计思想足以使它们理解这个系统。问题是当第一个版本发布之后，团队可能会解散，其它来维护这个系统的人可能是一个新人，那么它就只有代码和测试结果，这就使得系统维护极其困难。如果给你1 万行代码，你会从什么地方开始，又如何去理解这个系统呢？所以，要么我们花时间在前三个阶段，写详细设计文档和设计图表；或者我们花时间在维护阶段，来发现我们的系统是如何工作的。这些方式都是不能直接产出代码的，也是花费比较高昂的。许多开发人员认为直接书写代码才是有产出的，设计模型和文档则不能。但是，在一个程序的项目团队中，这些任务都是必须被完成的。抛弃文档写作就能提高生产力吗？文档写到什么粒度，既能很好地指导编码和测试，又能不降低生产率呢？一直是困扰开发人员的一个难题。

  2 轻便性问题：系统要能适应技术变化

软件工业与传统工业相比，有其特殊性，它的发展速度令人吃惊。每年( 甚至更快) ，新技术就被发明并迅速流行起来，例如(Java, Linux, XML, HTML, SOAP, UML, J2EE, .NET, JSP, ASP, Flash, Web Services 等等) 。许多公司必须跟从这种改变，因为：

· 用户提出使用新技术的需求

· 新技术能够真正解决一些问题( 例如，XML 解决异构系统间的数据交换)

· 软件供应商停止对旧的技术提供支持新技术能够使得一些公司获得一些切实的好处，但是人们必须面临的困境就是，他们必须快速跳跃前进，而且必须忍受前期投资失去价值的现实，这无疑是非常痛苦的。情况更加复杂的是，新技术本身也在发生变化。它们也会不断推出不同的版本，而且并不能保证能完全做到向后兼容。软件供应商通常也只是对最近的2 到3 个版本提供支持。 现存的一些系统要么提供接口与新技术开发的系统连接，要么转向新技术。那些仍然使用旧技术的遗产系统必然需要和使用新技术开发的系统进行互连。那么我们的系统如果和某种技术紧密绑定，那么注定这个系统在跟随技术发展的道路上是步履沉重的，那么如何设计我们的系统才能够使得我们的系统足够地轻便，能够跟上技术前进的步伐呢？

  3 互操作性问题 ：不同系统之间要能通讯

软件系统很少能够孤立地存在，大多数都需要和其它系统进行通信。系统往往要使用多种技术来实现，他们之间也存在互操作的问题。现在我们往往在系统中使用组件，不同的组件使用各自最佳的技术来实现，他们之间也需要互操作。 不同的工具对于元数据的管理均有自己的策略，这就给元数据的共享形成了障碍，也降低了不同软件的互操作性。如何应对这些互操作的需求呢？能否有一个统一的解决方案呢？

4 文档问题：对文档的态度和提出保证文档质量的疑问

许多的开发人员总是认为编码才是他们的主要任务，文档可用性的支持可以缓一缓。最终写文档成了强制的任务，不是出于自愿的工作当然不能做好。这样文档质量当然不高。 能够检查文档质量的也只能是开发团队的人员，而他们讨厌写文档，所以他们也不愿更新文档。代码改变之后必须手工在文档中找出设计中需要更改的地方，虽然烦琐，但必须这么做，因为便于将来维护的系统。在代码层次上解决这一问题的方案就是能够便利地从代码中产生文档，使得文档是代码中不可分割的一部分。这种方案被一些语言所支持，比如Eiffel 和Java 语言。但是这种方案只能解决概要(low-level) 设计文档的问题，详细(high-level) 的设计文档仍然需要手工维护。对于一个复杂的系统，在抽象层次上描述系统的详细设计文档尤为重要。如何能够保持文档和代码的同步，而又不额外增加很多工作量呢？