關於TDD、BDD和DDD的一些見解

在實際的項目中，咱們可能隨時面對各類不一樣的需求，它的各個方面的要素決定了咱們所採用的開發模式。

好比，它的複雜度如何？全部的需求是否足夠清晰？開發人員對相關的業務是否足夠了解？項目的工期是否合理？種種問題，不一而足。這也決定了咱們可能面對不一樣的需求可能須要採用不一樣的開發模式。下面大概說幾種。

 

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層的設計，着重於業務的實現，所以不可避免的以貧血 模式爲基礎而存在。可是它最大的特別是將分析和設計結合起來，再也不使他們處於分裂的狀態，這對於咱們正確完整的實現客戶的需求，以及創建一個具備業務伸縮 性的模型，是有很大幫助的。