一、TDD：測(cè)試驅(qū)動(dòng)開(kāi)發(fā)

測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（Test-Driven Development, TDD）是敏捷開(kāi)發(fā)中的一項(xiàng)核心實(shí)踐和技術(shù)。針對(duì)每個(gè)功能點(diǎn)抽象出接口代碼，然后編寫(xiě)單元測(cè)試代碼。目前的一些模式對(duì)TDD的支持都非常不錯(cuò)，比如MVC和MVP等。

適合TDD這種模式的項(xiàng)目必須具備：

• 項(xiàng)目的需求必須足夠清晰，而且程序員對(duì)整個(gè)需求有足夠的了解。
• 項(xiàng)目的復(fù)雜度和依賴性要低。對(duì)于一個(gè)業(yè)務(wù)模型及其復(fù)雜、內(nèi)部模塊之間的相互依賴性非常強(qiáng)的項(xiàng)目，采用TDD反而會(huì)得不嘗失，這會(huì)導(dǎo)致程序員在拆分接口和寫(xiě)測(cè)試代碼的時(shí)候工作量非常大。另外，由于模塊之間的依賴性太強(qiáng)，我們?cè)趯?xiě)測(cè)試代碼的時(shí)候可能不采取一些橋接模式來(lái)實(shí)現(xiàn)，這樣勢(shì)必加大了程序員的工作量。

二、BDD：行為驅(qū)動(dòng)開(kāi)發(fā)

行為驅(qū)動(dòng)開(kāi)發(fā)（Behavior Driven Development,BDD）。BDD旨在消除TDD過(guò)程中可能造成的問(wèn)題。與TDD相比，BDD是通過(guò)編寫(xiě)行為和規(guī)范來(lái)驅(qū)動(dòng)軟件開(kāi)發(fā)。 行為和規(guī)范可能看起來(lái)與測(cè)試非常相似，但是它們之間卻有著微妙但重要的區(qū)別。

BDD更注重功能本身而非單純的測(cè)試用例運(yùn)行結(jié)果。BDD測(cè)試用例的描述采用了更加’繁瑣’的風(fēng)格，閱讀BDD的測(cè)試用例就像是閱讀一篇文檔。這正是為什么我說(shuō)BDD旨在消除TDD過(guò)程中可能造成的問(wèn)題的原因所在。BDD賦予的這種像閱讀句子一樣閱讀測(cè)試的能力有助于帶來(lái)對(duì)測(cè)試認(rèn)知上的轉(zhuǎn)變，有助于我們?nèi)タ紤]如何更好寫(xiě)測(cè)試。當(dāng)你可以流暢的閱讀自己寫(xiě)的測(cè)試，你自然可以寫(xiě)出更好更全面的測(cè)試用例。

BDD是基于系統(tǒng)行為的一種測(cè)試方法，該方法基于系統(tǒng)行為定義出很多用于開(kāi)發(fā)功能點(diǎn)的途徑。Given(給予操作條件)-When(執(zhí)行相關(guān)操作)-Then(得到預(yù)期結(jié)果)是用來(lái)編寫(xiě)測(cè)試用例的方法：

• Given（給予操作條件）：用戶輸入有效的登錄憑證
• When（執(zhí)行相關(guān)操作）：用戶點(diǎn)擊登錄按鈕
• Then（得到預(yù)期結(jié)果）：顯示成功的驗(yàn)證消息

三、ATDD：驗(yàn)收測(cè)試驅(qū)動(dòng)開(kāi)發(fā)

驗(yàn)收測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（Acceptance Test Driven Development，ATDD）技術(shù)，是從用戶的角度編寫(xiě)了一個(gè)驗(yàn)收測(cè)試。 它主要側(cè)重于滿足系統(tǒng)的功能行為。 該技術(shù)用于檢測(cè)代碼是否按預(yù)期工作。

注意：ATDD與BDD非常相似，它們之間的主要區(qū)別是：BDD更多的是聚焦功能點(diǎn)的行為，而ATDD是捕獲更精準(zhǔn)的需求。

四、DDD：領(lǐng)域驅(qū)動(dòng)開(kāi)發(fā)

領(lǐng)域驅(qū)動(dòng)開(kāi)發(fā)（Domain Drive Design, DDD）是一種以業(yè)務(wù)為導(dǎo)向的軟件設(shè)計(jì)方法和思路。我們?cè)陂_(kāi)發(fā)前，通常需要進(jìn)行大量的業(yè)務(wù)知識(shí)梳理，而后到達(dá)軟件設(shè)計(jì)的層面，最后才是開(kāi)發(fā)。而在業(yè)務(wù)知識(shí)梳理的過(guò)程中，我們必然會(huì)形成某個(gè)領(lǐng)域知識(shí)，根據(jù)領(lǐng)域知識(shí)來(lái)一步步驅(qū)動(dòng)軟件設(shè)計(jì)，就是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的基本概念。而領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的核心就在于建立正確的領(lǐng)域驅(qū)動(dòng)模型。

對(duì)于現(xiàn)在流行的微服務(wù)架構(gòu)，微服務(wù)的拆分一直都是微服務(wù)設(shè)計(jì)要解決的問(wèn)題，而拆分困境產(chǎn)生的根本原因就是不知道業(yè)務(wù)或者微服務(wù)的邊界到底在什么地方。換句話說(shuō)，確定了業(yè)務(wù)邊界和應(yīng)用邊界，這個(gè)困境也就迎刃而解了。

解：DDD 核心思想就是通過(guò)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)方法定義領(lǐng)域模型，從而確定業(yè)務(wù)和應(yīng)用邊界，保證業(yè)務(wù)模型與代碼模型的一致性。

注意：
對(duì)于簡(jiǎn)單的系統(tǒng)，如果后續(xù)業(yè)務(wù)不會(huì)有太大變化，那么就不適合用DDD。

五、持續(xù)集成CI

持續(xù)集成（Continuous Integration, CI），是指頻繁地（一天多次）將代碼集成到主干，然后放到CI Server上自動(dòng)化跑一遍，如果代碼有問(wèn)題就會(huì)原路打回來(lái)，這樣做的目的就是為了能夠盡早發(fā)現(xiàn)錯(cuò)誤，從而能即時(shí)在最短的時(shí)間內(nèi)定位你的錯(cuò)誤并且改正。

六、持續(xù)交付CD

持續(xù)交付（Continuous Delivery, CD）是在持續(xù)集成的基礎(chǔ)上，將集成后的代碼部署到更貼近真實(shí)運(yùn)行環(huán)境的「類生產(chǎn)環(huán)境」中，是一個(gè)更小粒度提交的過(guò)程。比如，我們完成單元測(cè)試后，可以把代碼部署到連接數(shù)據(jù)庫(kù)的 Staging 環(huán)境中Jj進(jìn)行測(cè)試。如果代碼沒(méi)有問(wèn)題，可以繼續(xù)手動(dòng)部署到生產(chǎn)環(huán)境中。

七、持續(xù)部署CO

持續(xù)部署（continuous deployment，CO）是持續(xù)交付的下一步，指的是代碼通過(guò)評(píng)審以后，自動(dòng)部署到生產(chǎn)環(huán)境。

在持續(xù)交付后生成可執(zhí)行的制品，需要盡快驗(yàn)證是否存在功能性能等方面的問(wèn)題，或者盡可能快速的讓最終用戶可以使用這些功能。通過(guò)持續(xù)部署到測(cè)試環(huán)境、準(zhǔn)生成環(huán)境中，可以使測(cè)試團(tuán)隊(duì)盡快開(kāi)始測(cè)試，開(kāi)發(fā)團(tuán)隊(duì)獲得快速的反饋并響應(yīng)。使研發(fā)和測(cè)試的協(xié)同加快了進(jìn)程。通過(guò)持續(xù)部署到生產(chǎn)環(huán)境，讓最終用戶可見(jiàn)，則可以快速獲得最終用戶的使用反饋，體現(xiàn)需求的市場(chǎng)價(jià)值。

八、DevOps

DevOps （Development和Operations的組合詞）是一種重視“軟件開(kāi)發(fā)人員（Dev）”和“IT運(yùn)維技術(shù)人員（Ops）”之間溝通合作的文化、運(yùn)動(dòng)或慣例。透過(guò)自動(dòng)化“軟件交付”和“架構(gòu)變更”的流程，來(lái)使得構(gòu)建、測(cè)試、發(fā)布軟件能夠更加地快捷、頻繁和可靠。

分布式架構(gòu)+敏捷開(kāi)發(fā)模式

微服務(wù)架構(gòu)+DEVOPS

文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-461098.html

到了這里，關(guān)于軟件開(kāi)發(fā)方法論：TDD、BDD、DDD、ATDD、DevOps的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！