最近學習intern,在網站上看到一些不太理解的詞語:TDD,BDD, so百度了一下:
在實際的項目中，我們可能隨時面對各種不同的需求，它的各個方面的要素決定了我們所採用的開發模式。
比如，它的複雜度如何？所有的需求是否足夠清晰？開發人員對相關的業務是否足夠了解？項目的工期是否合理？種種問題，不一而足。這也決定了我們可能面對不同的需求可能需要採用不同的開發模式。下面大概說幾種。
1. TDD
TDD指的是Test Drive Development，很明顯的意思是測試驅動開發，也就是說我們可以從測試的角度來檢驗整個項目。大概的流程是先針對每個功能點抽象出接口代碼，然後編寫單元測試代碼，接下來實現接口，運行單元測試代碼，循環此過程，直到整個單元測試都通過。這一點和敏捷開發有類似之處。
TDD的好處自然不用多說，它能讓你減少程序邏輯方面的錯誤，儘可能的減少項目中的bug，開始接觸編程的時候我們大都有過這樣的體驗，可能你覺得完成得很完美，自我感覺良好，但是實際測試或者應用的時候才發現裏面可能存在一堆bug，或者存在設計問題，或者更嚴重的邏輯問題，而TDD正好可以幫助我們儘量減少類似事件的發生。而且現在大行其道的一些模式對TDD的支持都非常不錯，比如MVC和MVP等。
但是並不是所有的項目都適合TDD這種模式的，我覺得必須具備以下幾個條件。
首先，項目的需求必須足夠清晰，而且程序員對整個需求有足夠的瞭解，如果這個條件不滿足，那麼執行的過程中難免失控。當然，要達到這個目標也是需要做一定功課的，這要求我們前期的需求分析以及HLD和LLD都要做得足夠的細緻和完善。
其次，取決於項目的複雜度和依賴性，對於一個業務模型及其複雜、內部模塊之間的相互依賴性非常強的項目，採用TDD反而會得不嘗失，這會導致程序員在拆分接口和寫測試代碼的時候工作量非常大。另外，由於模塊之間的依賴性太強，我們在寫測試代碼的時候可能不採取一些橋接模式來實現，這樣勢必加大了程序員的工作量。
2. BDD
BDD指的是Behavior Drive Development，也就是行爲驅動開發。這裏的B並非指的是Business，實際上BDD可以看作是對TDD的一種補充，當然你也可以把它看作TDD的一個分支。因爲在TDD中，我們並不能完全保證根據設計所編寫的測試就是用戶所期望的功能。BDD將這一部分簡單和自然化，用自然語言來描述，讓開發、測試、BA以及客戶都能在這個基礎上達成一致。因爲測試優先的概念並不是每個人都能接受的，可能有人覺得系統太複雜而難以測試，有人認爲不存在的東西無法測試。所以，我們在這裏試圖轉換一種觀念，那便是考慮它的行爲，也就是說它應該如何運行，然後抽象出能達成共識的規範。如果你用過JBehave之類的BDD框架，你將會更好的理解其中具體的流程。這裏我推薦一篇具體闡述的文章。親身體驗行爲驅動開發。
另外，關於TDD和BDD之間的關係，還可以參考這篇文章: 虛擬座談會：代碼測試比率、測試驅動開發及行爲驅動開發
3. DDD
DDD指的是Domain Drive Design，也就是領域驅動開發。這是一種非常好的思想，在我們剛開始學習程序，甚至剛開始學習三層架構的時候，我們曾經面臨過很多疑惑，比如如何來實現我們的數據層？後來我們開始學習MVC，MVP等架構，如何設計Model層又成了我們的新問題。我們見過太多這種情況，Model變成了單純的數據容器，也就是我們經常說的貧血模式。DDD實際上也是建立在這個基礎之上，因爲它關注的是Service層的設計，着重於業務的實現，因此不可避免的以貧血模式爲基礎而存在。但是它最大的特別是將分析和設計結合起來，不再使他們處於分裂的狀態，這對於我們正確完整的實現客戶的需求，以及建立一個具有業務伸縮性的模型，是有很大幫助的。