程序设计方法的演化及极限（4）

5．程序设计方法的极限

软件工程发展的一个侧重方向是对软件开发过程中分析、设计的方法的研究。这方面的第一个重要成果就是在70年代风靡一时的结构化开发方法，即PO(面向过程的开发或结构话方法)。 PO是人们在用计算机世界来表达现实世界时，追求过程话、模块化、封装以及更高的抽象的结果。人们用计算机来映射现实世界时，最低层的实现无非是靠数字电路技术产生的高电平与低电平信号。在PO中，人们关注的是如何用函数和过程来实现对现实世界的模拟，将其映射到计算机世界之中。 OO是这种抽象层次不断提高的过程的自然发展结果，它采用类和对象的概念，把变量以及对变量进行 *** 作的函数和过程封装在一起，用这种更高一级的抽象来表达客观世界。通常，一个对象包含一些属性和方法，它对应于自然语言中一个有意义的名词，描述了现实世界中的一个物体(物理实体)或概念(抽象实体)。

我们知道，软件工程的发展历史就是人们不断追求更高的抽象、封装和模块化的历史。OO当然不会是历史的终结。尽管不能精确得到OO之后是什么，我们至少可以推知，OO之后的XO，必然将是比OO更高一级的抽象。它所依赖的核心概念必然高于并包容对象这一概念。正如对象高于并包容了函数和变量一样。

OO之后是什么呢?可能是FO--Function Oriented（面向泛函）。这里的Function不同于我们在当前编程所用备辩团的函数Function，这里的Function指职能模块高级抽象。所谓职能模块，是指可独立完成特定任务，而对无力完成的任务可自行找到具备完成该任务功能的其它职能模块，并与之建立联系以合力完成工作的功能体。FO 需要高速智能、智能接口、分布式技术、并行技术，最重要的是需要一个国际化的机构。

假如，OO之后是FO，那么我们当然要问FO之后会是灶尺什么呢?再往下又会是什么，有没有一个极限呢？如果有极限是什么呢？如果从计算机和数学理论回答这个问题是很困难的，但是，我们换个角度，以哲学的观点来分析这个问题。现实世界中的任何事物都有其发生、发展、成熟和灭亡的过程，假如把程序设计方法是一个事物，那么它也应该有其发生、发展、成熟和灭亡的经历。正如最初是不存在程序设计方法这个概念，随着计算机硬件的发展，出现了SP方法，紧接着就是OOP方法，到后OOP时代…，程序设计方法也遵循着这样一个自然规律。也就是说，程序设计方法肯定是有其极限的，可能若干年后我们所需要的不在是程序设计方法这样一个概念了，而是在更抽象的层次上智能的生产软件。 现在让我们假设软件工程已经发展到了这样一个理想的境界，有一天我们实现了自然语言编程，是否就万事大吉了？换句话，自然语言是否能很好地描述、表达客观感知仿橘世界？维特根斯坦在《逻辑哲学论》里已经指出：世界的意义必定存在于世界之外；实际上存在着不可表达的东西；这显示了它的存在，它是神秘的；也就是说，外部世界中存在一些我们可以感知却无法用语言来表达的东西；“对于那些不可言说的，必须保持沉默”这句话，成为我们最后的极限。

极限编程(Extreme Programming，XP)是一门针对业务和软件开发的规则，它的作用在于将两者的力量集中在共同的、可以达到的目标上。它是以符合客户需要的软件为目标而产生的一种方法论，XP使开发者能够更有效的响应客户的需求变化，培仿哪怕是在软件生命周期的后期。它强配迟纤调，软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分旦返利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用。极端编程属于轻量级的方法，认为文档、架构不如直接编程来的直接。

软件开发的过程是：需求分析、设计、编码和测试。

需求分析：不仅仅是用户需求，应该是开发中遇到的所有的需求。比如，你首先要知道做这个项目是为了解决什么问题；测试案例中应该输入什么数据……为了清楚地知道这些需求，你经常要和客户、项目经理等交流。

设计：编码前，肯定有个计划告诉你要做什么，结构是怎样等等。你一定要按照空皮槐这个来做，否则可能会一团糟。

编码：如果在项目截止日，你的程序不能跑起来或达不到客户的要求，你就拿不到钱。

测试：目的是让你知道，什么时候算是完成了。如果你聪明，你就应该先写测试，这斗友样可以及时知道你是否真地完成了。否则，你经常会不知道，到底有哪些功能是真正完成了，离预期目标还差多远。 定义每个用户需求的商业优先级；

制握禅订总体计划，包括用多少投资、经过多长时间、达到什么目的；

在项目开发过程中的每个工作周，都能让投资获得最大的收益；

通过重复运行你所指定的功能测试，准确地掌握项目进展情况；

能随时改变需求、功能或优先级，同时避免昂贵的再投资；能够根据各种变化及时调整项目计划；

能够随时取消项目；项目取消时，以前的开发工作不是一堆垃圾，已开发完的功能是合乎要求的，正在进行或未完成的的工作则应该是不难接手的。 知道要做什么，以及要优先做什么；

工作有效率；

有问题或困难时，能得到客户、同事、上级的回答或帮助；

对工作做评估，并根据周围情况的变化及时重新评估；

积极承担工作，而不是消极接受分配；

一周40小时工作制，不加班。 灵巧的轻量级软件开发方法

一套软件开发方法是由一系列与开发相关的规则、规范和惯例。重量级的开发方法严格定义了许多的规则、流程和相关的文档工作。灵巧的轻量级开发方法，其规则和文档相对较少，流程更加灵活，实施起来相对较容易。

在软件工程概念出现以前，程序员们按照自己喜欢的方式开发软件。程序的质量很难控制，调试程序很繁琐，程序员之间也很难读懂对方写的代码。1968年，Edsger Dijkstra给CACM写了一封题为GOTO Statement Considered Harmful的信，软件工程的概念由此诞生。程序员们开始摒弃以前的做法，转而使用更系统、更严格的开发方法。为了使控制软件开发和控制其它产品生产一样严格，人们陆续制定了很多规则和做法，发明了很多软件工程方法，软件质量开始得到大幅度提高。随着遇到的问题更多，规则和流程也越来越精细和复杂。

到了今天，在实际开发过程中，很多规则已经难于遵循，很多流程复杂而难于理解，很多项目中文档的制作过程正在失去控制。人们试图提出更全面更好的一揽子方案，或者寄希望于更复杂的、功能更强大的辅助开发工具（CaseTools），但总是不能成功，而且开发规范和流程变得越来越复杂和难以实施。

为了赶进度，程序员们经常跳过一些指定的流程，很少人能全面遵循那些重量级开发方法。

失败的原因很简单，这个世界没有万能药。因此，一些人提出，将重量级开发方法中的规则和流程进行删减、重整和优化，这样就产生了很多适应不同需要的轻量级流程。在这些流程中，合乎实际需要的规则被保留下来，不必要的复杂化开发的规则被抛弃。而且，和传统的开发方法相比，轻量级流程不再象流水生产线，而是更加灵活。

ExtremeProgramming（XP）就是这样一种灵巧的轻量级软件开发方法。

为什么称为“Extreme”（极限）

“Extreme”（极限）是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。

---