11｜作為工程化方法的TDD：更低的成本與更高的效能
TDD 的流程
如上圖所示，使用 TDD 的核心流程為：
首先將需求分解為功能點(diǎn)，也就是將需求轉(zhuǎn)化為一系列可驗(yàn)證的里程碑點(diǎn)；
如果已經(jīng)存在架構(gòu)或架構(gòu)愿景，則依據(jù)架構(gòu)中定義的組件與交互，將功能點(diǎn)分解為不同的功能上下文；
如果尚不存在架構(gòu)愿景，則可以將功能點(diǎn)作為功能上下文；
將功能點(diǎn)按照功能上下文，分解為任務(wù)項(xiàng)。也就是進(jìn)一步將可驗(yàn)證的里程碑點(diǎn)，分解為功能上下文中可驗(yàn)證的任務(wù)項(xiàng)；
將任務(wù)項(xiàng)轉(zhuǎn)化為自動(dòng)化測(cè)試，進(jìn)入紅 / 綠 / 重構(gòu)循環(huán)，驅(qū)動(dòng)功能上下文內(nèi)的功能實(shí)現(xiàn)；
如果重構(gòu)涉及功能上下文的重新劃分，即提取 / 合并組件，即視作對(duì)于架構(gòu)的重構(gòu)與梳理。需調(diào)整后續(xù)功能點(diǎn)中對(duì)于功能上下文以及任務(wù)項(xiàng)的劃分。
如此往復(fù)，直到所有功能完成。
通過上述過程的描述，可以發(fā)現(xiàn)任務(wù)列表中的任務(wù)項(xiàng)源自兩層分解：源自對(duì)于業(yè)務(wù)理解的功能點(diǎn)分解，以及源自架構(gòu)愿景的功能上下文分解。
功能點(diǎn)分解幫助我們形成可驗(yàn)證的里程碑點(diǎn)。這些里程碑點(diǎn)可看作由可工作的軟件（Working Software）構(gòu)成的進(jìn)度度量。功能上下文分解幫助我們找到正確的單元，指導(dǎo)我們保持良好的軟件架構(gòu)。
如果功能點(diǎn)分解錯(cuò)誤，那么就得不到功能正確的軟件；如果功能上下文分解錯(cuò)誤，那么就得不到架構(gòu)良好的軟件。
TDD 的工程優(yōu)勢(shì)
所以，使用 TDD 開發(fā)軟件對(duì)人的要求，與其他所有軟件工程方法對(duì)人的要求是一樣的：理解需求，明白架構(gòu)。但是 TDD 提供了這樣幾點(diǎn)在工程管理上的優(yōu)勢(shì)。
第一，理解需求等于可以針對(duì)功能點(diǎn)寫出測(cè)試。換句話說，寫不出測(cè)試就是不理解需求。不理解需求就不要開發(fā)。在不理解需求的前提下開發(fā)功能點(diǎn)，只能帶來負(fù)的進(jìn)度。從工程管理角度上看，“判斷一個(gè)人是否理解了需求”的成本極高。
第二，不寫測(cè)試，除了不會(huì)寫測(cè)試之外，就是沒理解需求。沒理解需求就去寫測(cè)試，那就是瞎干，瞎干不如不干。如果整個(gè)團(tuán)隊(duì)都寫不出測(cè)試，那么說明這個(gè)需求無法通過可管控的工程化方式交付。
可管控的工程化方式交付，意味著這個(gè)需求在實(shí)現(xiàn)層面上可以被執(zhí)行，也就是高確定性的。在高確定性的環(huán)境下，要追求效率。
而無法通過可管控的工程化方式交付，意味著不確定這個(gè)需求在實(shí)現(xiàn)層面上是否可被執(zhí)行，需要進(jìn)入探索模式。在不確定的情況下，要追求低成本及時(shí)止損。
第三，所有軟件從業(yè)人士都認(rèn)為架構(gòu)是重要的，但卻很少有人理解架構(gòu)究竟是如何發(fā)揮作用的。架構(gòu)并不是停留在紙面上的框圖，而是約定了構(gòu)成軟件系統(tǒng)的組件，以及組件之間的交互方式。也就是說，架構(gòu)是組件職責(zé)劃分的依據(jù)以及組件的交互模式。
