FDD——天才的灵感

totoo130

实际上大家并不知道FDD的agile方法的法律地位是很值得推敲的——至少你看那17个人中间没有Jeff De Luce和Peler Coad（http://www.agilemanifesto.org/）。而且即使是Jon Kern也是在相信agile对于建模的态度是友好的（至少MDA的Steve Mellor也这样认为），而且Together soft可以减小建模和编码之间的断层隔离。当然类似的处境也在Lean方法中出现。不过好在Agile方法系统不是武侠小说中的武林门派，不会有什么座次和正统的争吵。然而即使是现在，依然有人以为FDD是一种黑客方法学——FDD竟然敢自称为一种Processes，并且仅仅只需要10页的A4文件来表达（http://www.nebulon.com/articles/fdd/latestprocesses.html）。在这10页面前，我任何对于这个过程实施步骤的介绍都已经显得多余，不如我对于其中的某些环节进行集中的研究和讨论更有价值。

首先FDD没有强求你使用color UML，但是我实在找不出比这个方法更加简单明了的领域建模的方法了。问题领域内被认为存在四种类的模版，粉红的Moment/Interval,黄色的Role，绿色的PPT（Party,Place,Thing），蓝色的Description。而Domain Neutral Component是一种在业务系统中反复出现的模式，用我的话来说就是什么人在一个什么时间以一种什么身份做什么样的事情。我相信有的人可能不知道什么是名词，但是他也能把一件事情按照上面的格式来表达。当初我曾经交给我的客户使用CRC卡片建模，他们并没有觉得有什么复杂。而当我给他们color UML的时候，客户觉得比CRC还简单明了，并且感觉自己也可以做一个程序员。

而Feature——<action><resule><object>，也非常简单明了。不过很多人会误解Feature是一种表达需求的手段，就如同Use Case和Usestoris一样，其实他们都是对于需要的分析手段。只不过Feature更加靠近程序，而Use Case更加靠近业务，Usestory则可以被使用在这两种风格——但是一个Usestory只有一个风格。也就是说一个Use Case或者Usestory可以用几个Feature来进行构造。更加奇妙的是使用Feature可以很量化的表示你的开发进度，领域走查1%，设计40%，设计审查3%，编码45%，代码审查10%，提交构造1%。当然你可以根据你组织的具体情况来调整这个数据，不过只要你不是太频繁的调整，那么任何人都能够即时的知道你究竟过的好不好。使用Feature你会发现客户可以直接理解你程序的结构和进度，而不仅仅是通过你提交的文档的估计。当然这个能力对于很多习惯作假的人是深恶痛绝的。

同时我们会发现如果长期使用FDD在一个领域或者几个相关领域进行程序开发，那么领域模型会愈来愈固定，而以此为基础的人员会愈来愈成为某个方面的专家。同时更多类似的Feature，会频繁的出现。以至于当你仅仅使用以前的Feature就可以分析出现在的客户业务存在的问题。也就是说使用color UML和Feature不仅仅可以对需求进行整理，还可以对业务进行整理。

而且如果你够敏感，你会发现FDD被称为Processes。确实FDD第一次的使用就是在一个大型的项目，并且最后结果很成功。并且就如同Lean一样，FDD这里大型项目的例子非常多——无论是从代码的数量，需求的复杂，参与的人员数量，进行的时间，这些方面来说大型项目并不是FDD所欠缺的。而在小型和中型项目上，FDD由于可以很好的记录经验，也可以取得很好的效果。同时由于FDD的过程太少了（才10页A4），因此很少有人有对他做裁剪的欲望。同时这个方法使用的技术也够简单明了，也很少能够被人所非议是不是不容易学习掌握。不过确实FDD的内容没有包括SCM和coding方面的内容，但是你可以结合XP的持续集成，TDD，重构来完善他。而且由于Feature的结构统一，以其为基础构造Test Case是更有指引性。况且由于FDD使用温和的代码责任，你也不会产生过分重构的问题。而由于Feature的粒度统一，对于控制check in和check out也方便，因此至少做到每日构建是容易做到的。

不过FDD由于必须有2个关键的人物——首席构架师和首席程序员，因此门槛并不低。同时由于FDD的客户参与度可以做的很高，那么团队的文化很容易受到其客户的文牍主义的影响。并且由于FDD的前期工作可能会很长，因此也很容易被人们搞成一场打着敏捷旗帜的重型方法会展。不过好在如果你提前意识到这三个方面的问题，它们就可以预防。

原文 http://www.javaeye.com/topic/26162