笑谈PDD——仅为调侃

1. 何为PDD

中国是一个不擅长创造概念的国家,然而,在软件的世界里,中国却开创了一个新的名词——称之PDD。

PDD——Page-Driven Develop(页面驱动开发)。

2. 适从于企业的软件开发

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

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

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

组长下令:

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

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

3. 浅解PDD

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

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

4. PDD之诡辩

为什么要采用PDD呢?

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

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

这就是PDD的由来。

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

5. 业务从何而来

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

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

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

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

6. TDD的核心

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

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

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

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

7. 什么叫页面先行

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

8. PDD的坏处

A. PDD的代码是不可重用的:

最简单的逻辑,如果分给每个开发人员若干个页面,让开发人员依照这些页面进行开发,那么每个开发人员都会去找,每个按钮是做什么的,每个下拉框要回发什么数据。这就必然导致,每个人都是双击Button,然后在后台编写Button_Click方法,这样是最快的,也是最贴近开发人员思维的。

这样就必然导致了,每个开发人员的代码是不可重用的。因此想用PDD来开发出真正分层的程序,真的是异想天开。分层是先有层,后有代码。而绝非先有代码,后有层

由于太多的企业这样去做,所以在后台代码出现了上百行,甚至上千行代码,也不是不可理解了。错在哪?不是开发人员,而是领导人员。

B. PDD是无法知人善用的

我在读大道至简之我见1——团队管理中提到:作为一个管理者,必须具备”知人善用“的素质。

那么,PDD是以页面为功能切分功能的,这样也就意味着,每个开发人员都需要具备从前台CSS/Javascript,到C#,到SQL一系列的能力。

人无全才,很少有人既是Javascript牛人,又是DBA的数据库级别,因此,这样写出的代码,不可能是完整的。必然会导致,每个功能点都会有着这样的或者是那样的缺憾。

C. PDD是在整体项目进度上是缓慢的

对于一个商务项目来说,应该是以业务为驱动的,这样,每个人都可以负责自己专属的一部分。

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

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

D. PDD和面向对象的不兼容性

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

9. PDD的产生原因

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

A. 从玩具到项目的过渡

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

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

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

B. 信任危机

这个是非技术原因,仅为企业原因。

对于很多项目经理,开发主管,产品经理等来说,他们很多是不信任手下的开发人员的,他们需要每天都能看到,我手下的人,今天做了哪些工作。

那么什么是最直观的呢?页面。我今天做了十个页面,恩…. 不错。你今天做了一个页面,开除….

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

这也就是我所说的:信任危机。

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

10. PDD的应对之道

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

A. 观念的转变

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

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

B. 时刻考虑重用

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

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

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

C. 信任下属

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

D 设立正确的作业和里程碑

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

11. 总结

以上就是我对PDD的一些概括,仅为调侃之文。

拍吧……..

 

posted @ 2010-02-07 22:57  飞林沙  阅读(...)  评论(...编辑  收藏