笑谈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的一些概括，仅为调侃之文。

拍吧……..