天瓏網路書店 | BDD in Action, 2/e (中文版)最近天瓏在打新(舊?)書，很久以前就看過這本，不過我覺得 BDD 精神值得推廣就也順便推薦一下。BDD 的流派就是讓規格說明也是程式碼的一環。你可能會忘了改文件，但你不會忘了改 code，code 沒改程式(測試)就跑不起來。跑得起來文件就是正確的。
雖然落實在現實有很多困難，網路上跑教條式的 BDD 只會跟你說要寫什麼 Given Then 三小的東西，但 BDD 最重要的還是程式碼即文件的精神，而不是把 Spec 寫的像測試。測試歸測試，文件寫出來是要讓人讀的。
個人幹過一些土炮類型的東西，我是覺得有落實程式碼即文件的精神，近期的話像是從 code 直接產出 swagger (敝公司不是用 fastapi，所以這段純手刻。)
作法是去抓 function 的 input 值和回傳值 annotation (包含正常情況和錯誤)。
如果我回傳了 MySecondError 卻沒有在 return annotation 加上此 error 的話，程式就會出現紅線。當我加上了 MySecondError，紅線被消除，且下次產出 swagger 的時候一定也會包含此錯誤。
很難出現程式碼與文件不一致的情況，除非有人不開 linter 寫 code。
作法是去抓 function 的 input 值和回傳值 annotation (包含正常情況和錯誤)。
如果我回傳了 MySecondError 卻沒有在 return annotation 加上此 error 的話，程式就會出現紅線。當我加上了 MySecondError，紅線被消除，且下次產出 swagger 的時候一定也會包含此錯誤。
很難出現程式碼與文件不一致的情況，除非有人不開 linter 寫 code。
遠一點的話，則是直接輸出遊戲人物的狀態機轉換給 PM 看。我不會期待人物互動這麼複雜的東西，PM 可以像個工程師一樣把每一個狀況都細緻考慮到(不然他來當工程師就好了...)，並畫出狀態機列表給工程師實作。所以 PM 會把期望的東西寫個狀態機草稿，然後我 implement 後，因應一些沒考慮的狀況，我也許會補一些狀態上去。最後再把程式碼輸出為狀態轉換圖給 PM 做核對，看看與他心中想的一不一致。如果規格不一的話就可以再細調。
如果要修 bug，導致有狀態新增，也是工程師改完狀態新增完，就直接產出新版的狀態機規格。當程式和文件一致的時候，溝通摩擦就會小很多。
如果要修 bug，導致有狀態新增，也是工程師改完狀態新增完，就直接產出新版的狀態機規格。當程式和文件一致的時候，溝通摩擦就會小很多。
誠然蠻多地方是無法這麼做的，但是記住程式碼即文件的精神有益無害。能做到的部份就努力做，與其把文件外包在額外的檔案上，不如讓他是程式碼的一部分。畢竟(額外)文件會騙你，但程式碼不會。
天瓏網路書店 | Specification by Example 中文版：團隊如何交付正確的軟體 (S...如果只想看精神不想看工具的話也可以參考這本，內容不比 BDD in Action 差。
很讚的概念 我是自學的專案稍微大一點就很難管理了
