Terasoluna的程序设计（PD）

PD已经被我们抛弃很长时间了，然而最近的2个项目客户又重新开始要求PD了，并且下个项目也会做PD，到底PD怎么做，Terasoluna下PD应该做什么，大家有什么想法，之前2个项目的PD大家普遍认为没有意义，有时候反而写好了代码再去补PD。
既然存在这个过程，那么PD就肯定有它存在的意义，新时期的PD应该怎么做，是时候应该讨论一下了，不应该让PD成为我们的累赘，既然客户给了PD的时间，就要让PD发挥它实际的作用。

所以说，我们要研究一套好的方法，让PD做出来的东西对编码有帮助作用，而不是徒劳地浪费大家的时间
项目 中任何一项浪费时间的工作都会打消大家的积极性，任何消极的情绪都可能埋下祸根，如果认为PD浪费时间没有作用，那么干脆不要做，但是有时客户给了PD的 钱，就一定要有PD的成果物，这时候千万不能随便弄几个成果物糊弄过去，大多数时候可能客户也不是很懂，只是觉得流程中有这一步就应该做，具体做什么可能 他们也不清楚，如果一味听客户的就很可能造成我们浪费成本，因此重要的是要跟客户沟通好怎么做PD，只要能提出建设性的意见客户也不是傻子，还是会采纳 的。

综上，PD是为M服务的，不能白白浪费时间，因此我们可以把M部分的一部分成果物拿到PD工程来做，从TERASOLUNA的PD流 程来看，最重要的莫过于物理名称付与，这也确实是应该在PD做的事情，PD过程把物理名称写好，做好Review，可以避免进入大规模开发后命名不统一的 问题。
另外，SQL的编写也可以提前到PD阶段，按照式样书把SQL写好，通过工具测试一下，可以减轻编码时测试SQL的负担。
第三，共 通程序一览，共通函数的接口要在PD阶段确定下来，避免开始编码后由于共通接口不确定而导致编码停滞，也能够一定程度上避免共通化抽出不足。如果客户要求 做Class图的话，那么最应该做的就是共通类的Class图，其他业务类的Class图可以跟客户说因为使用了框架即使做出来也一样就不要做了，只出 JavaDoc就可以了。

以上是我想到的可以在PD阶段做的工作，都是对编码阶段有帮助的工作，既完成了PD的任务，有一定程度上减轻了编码的工作量，有机会大家试一下吧。

 

http://www.offshore-jp.com/html/75/n-1475.html