# 《Specification by Example 中文版》-- “前言 ~ 第五章” 心得 & 推坑 ###### tags: `推書 & 推坑` --- > 讀書會或是 workshop 怎麼進行 以從業工程師的標準，還有時間來看，我建議從第五章開始進行正式的讀書會，或是 workshop。前面的章節建議自己讀，或是用線上討論、FAQ 的方式進行。 > 沒有包袱的團隊學習應該更快 原本沒有 “正規” (“古典”) 系統分析能力的團隊，實踐實例化規格的門檻，反而可能會比較低。不過這也僅代表沒有既有的流程、工作方法包袱。 作者在書中會說明這些包袱的例子，甚至是現代開發方法的術語，會如何影響需求、技術團隊的溝通，以及本書如何解決這個問題。 > 實例化規格可以實現什麼 “手段” 弄出有人看得懂的規格、學會說故事：“正規” 系統分析的問題，總結就是回應變動的成本很高。還有應該給人、給大家看，大家應該要知道的規格，變成給工程師看、給電腦看的東西。 > 不能只會說故事 即使團隊很會講故事了，還是得有些落地、硬知識才能做開發。我覺得實例化規格的硬知識亮點、特別要注意的有 3 大重點：(總共有 9 大概念/術語/關注點) 1. 關鍵實例化規格 2. 可執行的實例化規格 3. Living documentation > 沒有銀彈 第二章開始，會帶入 just-in-time 的概念。這表示軟體開發、需求對齊，一直都不是學了之後會有 SOP，可以放空做完工作的事情。 而現代軟體開發方法，是為了把資源從花在救火，改為用在有效的 “燒腦” 與產出工作上 -- 事情沒有變輕鬆，但是會變簡單。這也是經典的《人月神話》提到的 “沒有銀彈”。 > 會學到什麼實務、實踐技能 這本書盡量不帶入一堆術語，而是用泛化的模式，和案例，反過來說明 BDD、ATDD 的 what、why 與 how。雖然沒有直接的說明，但是從案例中，可以理解到： * “單元測試” 和 TDD 有什麼不同 * BDD 的測試案例為什麼要 “這樣寫” (為什麽不是先有 “功能” ，再看著 API / UI “編故事”、“翻譯” 測試案例) 實務技能的部分： * 商業目標與範圍：User story；在後面的章節，也可以了解到 ``As a, I want to, so that ...`` 撰寫方式的意義 * 關鍵實例化規格、可執行的實例化需求規格：測試案例、測試案例程式碼 * Living documentation：可以理解為如何整理好，寫出好的 user story。“現代” 的測試案例即文件、DbC ...，都很好很重要、可以是 “活的” 文件，不過並非 living documentation 的目的 > 後續挑戰 找到團隊中願意陪你玩的人，一起來找出商業目的範圍、關鍵實例，提煉實體化規格；或者再務實一點，先練習寫好 user story。 > 陷阱 《Specification by Example》的手段，是把原本用在救火的腦力，更有效率的用在持續開發，預知、應付變動上。意思是 SBE 可以讓事情變 “簡單”，但不會更 “輕鬆” -- 事情一樣、甚至會更燒腦。 所以實作上要看團隊的能力、剩餘能量來調整，或是放棄 SBE。例如團隊原本習慣看著 “正規” (“古典”) 的規格書，做著 typing 的開發工作，或是只有 coding 的經驗，那麼應對的方法就要跟著調整。