简明现代魔法 -> 互联网时代 -> 关于页面驱动开发

关于页面驱动开发

2010-04-06

何为PDD

中国是一个不擅长创造概念的国家,然而,在软件的世界里,中国却开创了一个新的名词——称之PDD。PDD——Page-Driven Develop(页面驱动开发)。

适从于企业的软件开发

中国大多数的公司是什么开发现状我不清楚,只知道太多的人说:敏捷不适合我们,TDD不适合我们,XP不适合我们,螺旋也不适合我们。

那么我们要做什么呢?我们要找到一条我们企业自己的软件开发理论。于是乎,太多的企业开始的自己的探索之路。创造出了“XXXX公司”的软件工程,“适用于中国互联网”的软件工程……

在某次培训后,老大大笔一挥,我们要在项目中适用TDD。

组长下令:

“OK。然而,TDD不适合于我们的项目,也不适合我们企业。那我们灵活应对,TDD的核心是什么,是”DD”,我们把握住这个DD,先做页面……”

我笑,控制不住的笑,我又接触到了一个名词,那就叫PDD吧。

浅解PDD

谈起PDD,也许大家都很陌生,但是我想当我详解PDD之后,大家会觉得:哦!原来是这么一回事啊,在我刚刚学软件的时候,原来我们一直都在用PDD的开发模型。

什么是PDD。PDD就是一切以页面为核心,然后每个程序员针对每个页面来找到功能点,从而以页面为单位进行任务交付。

PDD之诡辩

为什么要采用PDD呢?

我们按照传统的思维来走,一切应该是以业务来驱动开发,我们甚至可以称之为BDD(Business-Driven Develop)。那么业务从哪里来?从界面来,所以我们要以页面为单位来驱动开发程序。

有一种说法是,开发未动,页面先行,这也是PDD的一个理论基础。

这就是PDD的由来。

那下面就来剖析下PDD究竟错在哪里。

业务从何而来

页面从页面而来,这似乎成了PDD最大的理由。这里我想说:也许业务逻辑可以从界面而来,但是他在这里忽略了角色的概念。

在一个项目团队中,一定要有着一个人来承担着,需求产品方与开发人员之间的桥梁,这个人员按照常理上应该叫做”需求分析人员“。在很多企业中,这个角色一般由项目经理或者开发经理来担任。

需求调研的方式有很多,比如问答,调查问卷,甚至于是说从页面而来。

但是对于开发人员来说,这些一切都是透明的,业务从何而来?是从项目经理的文档中而来。对于一个项目来说,应该是从设计文档中而来。而绝不是页面。

TDD的核心

个人一直认为,如果当你对一个概念,对一个理论没有充分地理解时,千万不要对其随便去改造,变化。

TDD的核心是什么,不是DD,而是那个T。

TDD强调的是:开发为做,测试先行。保证了每个完整的业务逻辑都是正确的,更重要的还有一点就是这个T的可重用性。

个人对TDD并没有什么认识,在此就不多说了。

什么叫页面先行

什么是页面先行,也许很多人都被这个页面误导了。在我看来,与其说页面先行,倒不如说原型先行来得更合适。

PDD的坏处

PDD的产生原因

PDD因何产生,我个人总结出如下几点:

那么既然有了原因,应对之道是很简单的吧。

PDD的应对之道

提出了问题,就要解决问题,那么我们如何来应对PDD(不知道这能否算是一种反模式的解决方案)。

极限编程为什么不极限?我们已经按照教科书、Jcobson、MatinFowler的做了,用了测试驱动,用了小卡片,用了standmeeting,可是结果只是一个人干多个人的工作,让大公司变成小作坊,小作坊变成单兵作战。

传统的软件开发,从用例、需求文档、代码设计、代码开发、测试。这个流程非常的顺利,技术也比较成熟。可是问题出现在了开发开发完成后,实际代码和文档有很大的出入(如果没有出入,我估计八成是强迫了顾客接受之前确定的需求文档。)

所以,传统的XP,实际上和soho一族差不多,就是让大公司的编程变得灵活,但是问题就是过程没有经典的瀑布模式产生规范的文档。

因此极限完毕了,就需要花相同的时间去重新写用例、需求文档。这个过程似乎还没有成熟的技术。就是一种reverse engineering,反向编程,我称为反向极限——Reverse eXtreme Programme——RXP。

软件开发过程,我分为四类:

前三者,和传统的组件类似,内部的代码结构经过了精细优化,使用了大量设计模式,较难使用极限编程技术;但是有个特点是:用户并不关心他们的内部构造,他们只需要知道如何调用、调用返回值。

所以,只要开发完成,用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();
         
	CreateItem(itemtable);
 
	CreateItemPrice(itemtable);
         
	CreateItemInventory(itemtable);
 
	UpdateUserProfile(itemtable);
}

这是个创建商品的页面 manager_create_item.aspx,当用户点击了button_commit之后,创建商品数据、商品价格数据、商品库存数据、更新个人信息表。这个就是一个Use Case,需求用例。

随机文章推荐
网站分类


注:如需转载本文,请注明出处(原文链接),谢谢。更多精彩内容,请进入简明现代魔法首页。

进入新博客
喜欢本文,就分享它吧
给我留言
您的名字:
您的邮件:
您的网站:


 

copyright © 2009 简明现代魔法    学习、分享、进步

power by Gonn 感谢所有关心和支持本站的朋友们