FDD——天才的靈感

totoo130

實(shí)際上大家并不知道FDD的agile方法的法律地位是很值得推敲的——至少你看那17個人中間沒有Jeff De Luce和Peler Coad（http://www.agilemanifesto.org/）。而且即使是Jon Kern也是在相信agile對于建模的態(tài)度是友好的（至少M(fèi)DA的Steve Mellor也這樣認(rèn)為），而且Together soft可以減小建模和編碼之間的斷層隔離。當(dāng)然類似的處境也在Lean方法中出現(xiàn)。不過好在Agile方法系統(tǒng)不是武俠小說中的武林門派，不會有什么座次和正統(tǒng)的爭吵。然而即使是現(xiàn)在，依然有人以為FDD是一種黑客方法學(xué)——FDD竟然敢自稱為一種Processes，并且僅僅只需要10頁的A4文件來表達(dá)（http://www.nebulon.com/articles/fdd/latestprocesses.html）。在這10頁面前，我任何對于這個過程實(shí)施步驟的介紹都已經(jīng)顯得多余，不如我對于其中的某些環(huán)節(jié)進(jìn)行集中的研究和討論更有價值。

首先FDD沒有強(qiáng)求你使用color UML，但是我實(shí)在找不出比這個方法更加簡單明了的領(lǐng)域建模的方法了。問題領(lǐng)域內(nèi)被認(rèn)為存在四種類的模版，粉紅的Moment/Interval,黃色的Role，綠色的PPT（Party,Place,Thing），藍(lán)色的Description。而Domain Neutral Component是一種在業(yè)務(wù)系統(tǒng)中反復(fù)出現(xiàn)的模式，用我的話來說就是什么人在一個什么時間以一種什么身份做什么樣的事情。我相信有的人可能不知道什么是名詞，但是他也能把一件事情按照上面的格式來表達(dá)。當(dāng)初我曾經(jīng)交給我的客戶使用CRC卡片建模，他們并沒有覺得有什么復(fù)雜。而當(dāng)我給他們color UML的時候，客戶覺得比CRC還簡單明了，并且感覺自己也可以做一個程序員。

而Feature——<action><resule><object>，也非常簡單明了。不過很多人會誤解Feature是一種表達(dá)需求的手段，就如同Use Case和Usestoris一樣，其實(shí)他們都是對于需要的分析手段。只不過Feature更加靠近程序，而Use Case更加靠近業(yè)務(wù)，Usestory則可以被使用在這兩種風(fēng)格——但是一個Usestory只有一個風(fēng)格。也就是說一個Use Case或者Usestory可以用幾個Feature來進(jìn)行構(gòu)造。更加奇妙的是使用Feature可以很量化的表示你的開發(fā)進(jìn)度，領(lǐng)域走查1%，設(shè)計40%，設(shè)計審查3%，編碼45%，代碼審查10%，提交構(gòu)造1%。當(dāng)然你可以根據(jù)你組織的具體情況來調(diào)整這個數(shù)據(jù)，不過只要你不是太頻繁的調(diào)整，那么任何人都能夠即時的知道你究竟過的好不好。使用Feature你會發(fā)現(xiàn)客戶可以直接理解你程序的結(jié)構(gòu)和進(jìn)度，而不僅僅是通過你提交的文檔的估計。當(dāng)然這個能力對于很多習(xí)慣作假的人是深惡痛絕的。

同時我們會發(fā)現(xiàn)如果長期使用FDD在一個領(lǐng)域或者幾個相關(guān)領(lǐng)域進(jìn)行程序開發(fā)，那么領(lǐng)域模型會愈來愈固定，而以此為基礎(chǔ)的人員會愈來愈成為某個方面的專家。同時更多類似的Feature，會頻繁的出現(xiàn)。以至于當(dāng)你僅僅使用以前的Feature就可以分析出現(xiàn)在的客戶業(yè)務(wù)存在的問題。也就是說使用color UML和Feature不僅僅可以對需求進(jìn)行整理，還可以對業(yè)務(wù)進(jìn)行整理。

而且如果你夠敏感，你會發(fā)現(xiàn)FDD被稱為Processes。確實(shí)FDD第一次的使用就是在一個大型的項目，并且最后結(jié)果很成功。并且就如同Lean一樣，F(xiàn)DD這里大型項目的例子非常多——無論是從代碼的數(shù)量，需求的復(fù)雜，參與的人員數(shù)量，進(jìn)行的時間，這些方面來說大型項目并不是FDD所欠缺的。而在小型和中型項目上，F(xiàn)DD由于可以很好的記錄經(jīng)驗，也可以取得很好的效果。同時由于FDD的過程太少了（才10頁A4），因此很少有人有對他做裁剪的欲望。同時這個方法使用的技術(shù)也夠簡單明了，也很少能夠被人所非議是不是不容易學(xué)習(xí)掌握。不過確實(shí)FDD的內(nèi)容沒有包括SCM和coding方面的內(nèi)容，但是你可以結(jié)合XP的持續(xù)集成，TDD，重構(gòu)來完善他。而且由于Feature的結(jié)構(gòu)統(tǒng)一，以其為基礎(chǔ)構(gòu)造Test Case是更有指引性。況且由于FDD使用溫和的代碼責(zé)任，你也不會產(chǎn)生過分重構(gòu)的問題。而由于Feature的粒度統(tǒng)一，對于控制check in和check out也方便，因此至少做到每日構(gòu)建是容易做到的。

不過FDD由于必須有2個關(guān)鍵的人物——首席構(gòu)架師和首席程序員，因此門檻并不低。同時由于FDD的客戶參與度可以做的很高，那么團(tuán)隊的文化很容易受到其客戶的文牘主義的影響。并且由于FDD的前期工作可能會很長，因此也很容易被人們搞成一場打著敏捷旗幟的重型方法會展。不過好在如果你提前意識到這三個方面的問題，它們就可以預(yù)防。

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