趣谈PDD页面驱动开发

一个中国式的开发指导
服务器君一共花费了216.412 ms进行了5次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

何为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的代码是不可重用的:
  • 最简单的逻辑,如果分给每个开发人员若干个页面,让开发人员依照这些页面进行开发,那么每个开发人员都会去找,每个按钮是做什么的,每个下拉框要回发什么数据。这就必然导致,每个人都是双击Button,然后在后台编写Button_Click方法,这样是最快的,也是最贴近开发人员思维的。 这样就必然导致了,每个开发人员的代码是不可重用的。因此想用PDD来开发出真正分层的程序,真的是异想天开。分层是先有层,后有代码。而绝非先有代码,后有层。 由于太多的企业这样去做,所以在后台代码出现了上百行,甚至上千行代码,也不是不可理解了。错在哪?不是开发人员,而是领导人员。

  • PDD是无法知人善用的
  • 作为一个管理者,必须具备”知人善用“的素质。那么,PDD是以页面为功能切分功能的,这样也就意味着,每个开发人员都需要具备从前台CSS/Javascript,到C#,到SQL一系列的能力。 人无全才,很少有人既是Javascript牛人,又是DBA的数据库级别,因此,这样写出的代码,不可能是完整的。必然会导致,每个功能点都会有着这样的或者是那样的缺憾。

  • PDD是在整体项目进度上是缓慢的
  • 对于一个商务项目来说,应该是以业务为驱动的,这样,每个人都可以负责自己专属的一部分。

    例如SQL开发人员,前台美工,Javascript开发人员,后台开发人员,每个人都有自己的关注点,前台人员,后台人员不需要关心后台数据库的逻辑,就不至于每个开发人员在开发之前都需要先来了解前台的美工布局,又需要了解后台数据库的表结构,这样如果一个项目过大,就必然会让人做着无数重复的工作,比如我们每个人都需要详细了解表结构。

    其实,采用PDD方式,实际上是会让项目减缓的。

  • PDD和面向对象的不兼容性
  • 简而言之:面向对象是先有对象,后组装,而PDD是先有功能,后拆分,因此,PDD不可能开发出面向对象的程序。

PDD的产生原因

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

  • 从玩具到项目的过渡
  • 在校园里,很少有学生来能从头开始面对一个完整的大项目,而都是一些项目模块,或者是一些如”图书馆管理系统“之类的小项目。

    在这样的项目中,开发人员较少,甚至是独立开发。系统简单,逻辑清晰,从界面开发没有什么不可以的。但是到了工作中,你面对的不在是一个简单的”玩具“系统,而是一个真实的项目,里面可能会涉及到较为复杂的业务逻辑,会涉及到系统的,子模块之间的集成,也涉及到多人的团队合作开发。

    这样,再由于惯性才用PDD方式其实是并不适用的。

  • 信任危机
  • 这个是非技术原因,仅为企业原因。

    对于很多项目经理,开发主管,产品经理等来说,他们很多是不信任手下的开发人员的,他们需要每天都能看到,我手下的人,今天做了哪些工作。 那么什么是最直观的呢?页面。我今天做了十个页面,恩…. 不错。你今天做了一个页面,开除….

    所以,我要求把整个项目拆分成若干个页面,每个开发人员负责几个页面,每天把你负责的页面完成,让我每天都能感觉到,你今天确实在工作。 这也就是我所说的:信任危机。

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

PDD的应对之道

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

  • 观念的转变
  • 在项目中,不要因循守旧,说“我曾经是怎么做的”,我在前文中提过:成功是对过去经验的总结,而并非对过去经验的复制。我们要时刻记得,我是在做项目,不是在做玩具。

    因此,我们不要为了贪图方便,为了觉得“减少时间”而PDD,而是以业务逻辑为驱动。

  • 时刻考虑重用
  • 对于一个打算长期发展的公司来说,重用性和维护性都是非常重要的。那么如果时刻考虑重用,那么PDD就是行不通的。

    什么是重用性最高的代码,我总结为有两种特征:1. 原子性高的代码 2. 业务性较弱的代码

    第一点不用说,你的颗粒越小,能用到你的地方越多。就像1+1=2能被很多地方用到,但是1+1+1+1+1=5就很少有地方会用到。第二点,业务无关的代码可以被任何业务所使用,并不是说我插入图片的操作,我需要首先验证图片类型,然后保存到服务器,然后存到数据库,这属于一个完整的业务逻辑,今后其他地方只要上传图片,比如说,我的安全级别较低,不需要验证图片,那么我的这个方法就不能被重用。

  • 信任下属
  • 用人不疑疑人不用,这个道理应该是每个人都懂的,可是能做到的人很少。

  • 设立正确的作业和里程碑
  • 我在前面提到,很多主管以页面为交付单位,这就必然会造成PDD,那么我们是否考虑放弃以页面为交付作业和里程碑,而是以函数实现,类实现作为我们的交付基本单位呢?

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

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

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

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

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

  • 基本类库开发 Base.X
  • 例如字符串处理、加密解密等。特点是不针对特定的业务、领域。大量复用。

  • 框架类库 Framework.X
  • 针对某一功能点,不针对特定的领域。例如配置文件、数据库持久层、ORM等。基本复用。

  • 服务类库 Services.X
  • 针对某一功能点,针对特定的领域。一般结合了第三方的库,例如yahoo查询天气、飞信操作等,或者自己开发的应用。针对特定领域复用。

  • 应用开发 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();
         
	CreateItem(itemtable);
 
	CreateItemPrice(itemtable);
         
	CreateItemInventory(itemtable);
 
	UpdateUserProfile(itemtable);
}

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

本文地址:http://www.nowamagic.net/librarys/veda/detail/691,欢迎访问原出处。

不打个分吗? 还木有人打分噢!

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/691

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

大家都在看

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《编程之美:微软技术面试心得》 《编程之美》小组 (作者)

《编程之美:微软技术面试心得》是一本让人着迷的书!阅读起来。有些题目的内容会引起强烈的共鸣,尤其是那些自己非常熟悉并且又深知解答的题目;也有一些题目让我异常惊诧,原来除了我所知道的解答思路之外,还有更好的解答以及更深层次的原因。还有一些题目是从来没想到过的。阅读过程是一次愉快的享受,也是脑细胞持续活跃的过程。

更多计算机宝库...