團隊如何交付正確的軟體 - ch3 - 活的說明文件

一般來說， Spec. 實例化 (Specification by Example , SBE) 有兩種比較流行的模型

以驗收測試為中心的模型
- 通稱為「驗收測試驅動開發」(Acceptance Test-Driven Development, ATDD)
- 著重自動化測試，優點是可以使開發目標更明確，也能確實防止功能退化
以系統行為規範為主導的模型
- 通稱為「行為驅動開發」(Behavior-Driven Development, BDD)
- 著重於制定系統行為的場景，透過協作來釐清 spec ，建立專案關係人與交付團隊之間的共識。此模式也認為透過自動化測試來防止功能退化相當重要。

這兩種模式沒有優劣的分別，不同模型有不同的用途在，書中提到如果團隊有許多功能品質上的問題，那麼以驗收測試為中心的模型效用比較好。當一切運行順暢，針對中期或短期軟體的交付說明來說的話，以系統行為規範為主導的模型會比較好用。

這兩個模型中主要都是將 spec 可以去做實例化，共通的好處在於，透過自動化測試來預防功能的退化。

為什麼我們需要權威的說明文件

通常我們會遇到一種狀況，面對一個新的系統，我們會拿到一份「並不完全正確的系統文件」（如果很幸運你遇到的系統有文件的話），而我們深知要在修改完功能之後再文件上做出對應的修改是一件成本相當高的事情，所以往往我們也不會真的去看文件，而是直接從程式碼反覆推敲系統的各種運作，而這種逆向工程通常是一件無法完成的任務。

理想的方式是建立一個易於維護且維護成本低，即使頻繁修改底層的程式碼結構，也可以與系統功能保持一致的說明文件系統。

那麼，有什麼方式可以符合上面所說的說明文件系統呢？

測試可以是好的說明文件

而自動化測試則相反，要找出需要修改的地方相當容易，但找出來之後的程式修改卻不見得真的容易修改，以驗收測試為中心的模型方法，常常會忽略其容易帶來這樣的影響。

所以其重點在於，建立清楚及易於維護的測試，如果測試寫得很清楚，那麼其實就不需要其他類型的說明文件了。

但支援系統演進的不是測試，而是說明文件，所以建構出易於維護的說明文件才是我們的目的，而如果有可以自動化執行、且維護成本低、又描述得清楚的測試的話，那麼就剛剛好符合我們的目的了。

根據可執行的需求規格建立說明文件

當軟體系統持續的接受可以執行的 spec 的驗證時，我們的系統就會按照我們期望的運作模式去運作， spec 會與系統行為始終保持一致。而將這些實例化之後的 spec 蒐集起來，則是本書指的 Living Documentation。

以說明文件為中心的模型具備哪些好處

spec 實例化採用說明文件為中心的模型可以幫助團隊建立有用的說明文件
持續使用 spec 實例化並將他導入工作，往後便不需要花費大量的時間在系統考古跟驗證上
側重於業務程序的說明文件可以避免過度關心技術性的 spec ，還可以保持 spec 從系統角度去關心系統應該做的事，而不是關注在測試腳本上

但 spec 過去抽象可能是以說明文件為中心的模型的一個潛在陷阱。

重點回顧

spec 實例化有幾種不同的模型，不同的模型有不同的用途
spec 實例化可以讓你漸進式的建置一個良好的說明文件系統
Living Documentation 是交付程序的重要產物，與程式碼一樣重要
側重於建立業務程序的說明文件系統，可避免在長期維護 spec 和測試時所造成的大部分常見問題