页面驱动开发（Page Driven） —— 一种大多数人还不认同的技术
----------
前言
----------
极限编程为什么不极限？我们已经按照教科书、Jcobson、MatinFowler的做了，用了测试驱动，用了小卡片，用了standmeeting，可是结果只是一个人干多个人的工作，让大公司变成小作坊，小作坊变成单兵作战。
传统的软件开发，从用例、需求文档、代码设计、代码开发、测试。这个流程非常的顺利，技术也比较成熟。可是问题出现在了开发开发完成后，实际代码和文档有很大的出入（如果没有出入，我估计八成是强迫了顾客接受之前确定的需求文档。）
所以，传统的XP，实际上和soho一族差不多，就是让大公司的编程变得灵活，但是问题就是过程没有经典的瀑布模式产生规范的文档。
因此极限完毕了，就需要花相同的时间去重新写用例、需求文档。这个过程似乎还没有成熟的技术。就是一种reverse engineering，反向编程，我称为反向极限——Reverse eXtreme Programme——RXP。
本文就谈谈基于页面驱动（Page Driven）的反向极限的开发想法。
----------
正文
----------
软件开发过程，我分为四类：
1. 基本类库开发 Base.X
例如字符串处理、加密解密等。特点是不针对特定的业务、领域。大量复用。
2. 框架类库 Framework.X
针对某一功能点，不针对特定的领域。例如配置文件、数据库持久层、ORM等。基本复用。
3. 服务类库 Services.X
针对某一功能点，针对特定的领域。一般结合了第三方的库，例如yahoo查询天气、飞信操作等，或者自己开发的应用。针对特定领域复用。
4. 应用开发 Applications.X
针对特定功能点、特定领域。例如ERP系统、缺陷跟踪等。不可复用。
前三者，和传统的组件类似，内部的代码结构经过了精细优化，使用了大量设计模式，较难使用极限编程技术；但是有个特点是：用户并不关心他们的内部构造，他们只需要知道如何调用、调用返回值。
所以，只要开发完成，用API文档记录即可。日后基本上不需要维护。
------------------
应用开发的极限——页面驱动（Page Driven）
------------------
应用开发是最赚钱的，也是属于产品级别的开发。例如短信系统、财务系统、进销存系统等。
这种开发的特点是：代码就是文档。
比如一个销售过程，无论用什么语言去描述客户需求，还不如我们用代码描述直接。而且文档存在了细节上的遗漏，将来维护，看文档还不如看代码。
针对这个特点，在应用级别的开发，我个人主张以下几点：
1. 代码采用平铺直叙，不使用任何的设计模式，不使用任何重构技术。
2. 一个页面针对一个需求。
这样，一种开发驱动模式就出现了，就是页面驱动开发，Page Driven。 目前网上我仅能搜索到几篇论文，但是将来这种模式一定会“横行霸道”的。
一个典型的页面驱动开发过程：
1. 写用例、需求文档
2. 设计项目界面，制作原型系统
3. 根据原型系统，制作实际系统
4. 测试
5. 代码反向修正用例、需求文档。
前4点已经是陈词滥调，而第5点正是本文新颖之处。由于上文提到的页面开发特点，文档和代码非常容易对应，因此为反向极限提供了可能。请看一下代码：
代码
protected void button_commit_Click( object sender, EventArgs arg)
{
DataTable itemtable = GetItemTable();
CreateItemInventory(itemtable);
UpdateUserProfile(itemtable);
}
这是个创建商品的页面 manager_create_item.aspx，当用户点击了button_commit之后，创建商品数据、商品价格数据、商品库存数据、更新个人信息表。这个就是一个Use Case，需求用例。
我只要使用了反射，非常容易得到以下文档：
Use Case Template
| Use Case ID: |
xxxxxxxxxxxx |
||
| Use Case Name: |
Manager Create Item （页面manager_create_item词法解析） |
||
| Created By: |
Pixysoft |
Last Updated By: |
Pixysoft |
| Date Created: |
2010-04-04 |
Date Last Updated: |
2010-04-04 |
| Actors: |
省略 |
| Description: |
省略 |
| Trigger: |
User Commit （根据控件方法获取） |
| Preconditions: |
省略 |
| Postconditions: |
省略 |
| Normal Flow: |
1. Get Item Table 2. Create Item Information 3. Create Item Price Information 4. Create Item Inventory Information 5. Update User Information. （这些数据可以反射代码从调用方法获取） |
| Alternative Flows: |
省略 |
| Exceptions: |
省略 |
| Includes: |
省略 |
| Priority: |
省略 |
| Frequency of Use: |
省略 |
| Business Rules: |
省略 |
| Special Requirements: |
省略 |
| Assumptions: |
省略 |
| Notes and Issues: |
省略 |
基本上，从代码可以直接对应回需求文档。这样将来的开发，只要从需求文档生成代码模板；之后再反向更新需求文档，即可实现了反向极限，达到真正极限的目标。
------------
后记
------------
未来的极限开发，不是让代码越少越好、让文档越少越好；而是相反，代码、文档越来越正规化，正规到了可以大部分让机器去自动完成，我们工程师只需要在需要变动的地方手指头动动即可。