TDD 與 SDD

1. 軟體開發邪教的救贖
AI 時代更應掌握的 TDD 技能
Kuma

2. Kuma
緯雲股份有限公司
Tech. Lead

3. 我們在徵人
3

4. …
事件的起源
4

5. …
半年多以來他一直很生氣，但是他忘了一件事
5

6. KUMA WARNING
本演講意在與聽眾分享在 AI 盛行的現代，吾輩
TDD 教徒的開發方式如何與 AI 「相輔相成、相得
益彰」，藉以準時下班。今天不會教各位任何 AI
工具的密技。想學如何「用一句話叫 AI 做出一個
網站」的同學，請趁早離開。而期待「 SDD 密技
…
大公開」的同學，我認識一個朋友最近有在開課
6
就他！

7. 從「問題」的角度看 SDD
7

8. 什麼是 SDD ？
近年，因 LLM 技術成熟，「 AI 寫 Code 」儼然已成為顯學
ChatGPT →
打電話問功夫 五分鐘 Vibe →
出簡易網站 SDD
SDD ：用「文件即程式碼」連接開發與團隊。將文件當作程式碼管
理，達到「唯一事實來源」的效果。讓需求文件不再只是開發的附屬
品，而是真正融入開發生命週期的核心。
source: 天瓏書局
8

9. 9

10. 用「模式」的概念來理解世界
https://essenceofsoftware.com/tutorials/design-general/misfits/
● 人類在真實世界感受到的種種「不舒適」就是
Force
● 問題由 Force 組合而成
● 有了問題，我們就想找解決方案
● 針對一種特定的場景，不斷重複出現的問題，提出
的一個「已被證實有效」的解決方案，即為一個
「模式」。
● 尋求問題的解方有兩種方式：
○ Form Oriented
○ Context Oriented 10

11. 兩種尋求解方的方式 之 台語大考驗
11

12. 今年火速流行的 Specification Driven Development
是一種「 Form Oriented 」還是「 Context Oriented 」求解方式？
Pop Quiz ！
12

13. 在軟體開發中，要滿足功能，有哪些事要做？
Requirement
Analysis
Implement Test
Spec. Feature
人做
13

14. 當 AI …
來了
Requirement
Analysis
Implement Test
Spec. Feature
AI 做
人做
14

15. 那我這樣呢？不就 TDD 了？
Requirement
Analysis
Test Impl.
Spec. Protection
AI 做
人做
15

16. TDD 不就是「先寫測試再寫程式？」
16

17. …
「我的領域很複雜，分析很難一次到位，而且需求會一直改 」
17

18. 這時，你要怎麼確保這一段是「對」的？

19. 19

20. 我可不可以這樣？
Requirement
Analysis
Impl. Test
Feature
AI 做
人做
Analysis
Spec.
Impl. Test
Feature
Analysis
Spec.
Spec.
…
人做 AI 做
人做
20
可交付 可交付

21. … 或這樣？
Requirement
Analysis
Test Impl
Feature
AI 做
人做
Analysis
Spec.
Test Impl.
Feature
Analysis
Protection
Spec.
…
人做 AI 做
人做
Protection
Spec.
21
可交付 可交付

22. 啊，這不就 TDD 嗎？
Requirement
Analysis
Test Impl
Feature
AI 做
人做
Analysis
Spec.
Test Impl.
Feature
Analysis
Protection
Spec.
…
人做 AI 做
人做
Protection
Spec.
22
可交付 可交付

23. TDD 是：
source: Dave Farley interviewing Emily Bache
https://www.youtube.com/watch?v=6yb7jKpxTjM
23

24. source code:
可以拆到多小？
24

25. source code:
25

26. source code:
26

27. 有了 2 vs 2, 2 vs 3 ，下一個測項是什麼？
動腦時間： What Next?
source code:
27

28. 同為 High Card
One Pair 勝 High Card
同為 One Pair
Two Pair 勝 One Pair
同為 Two Pair
三條 勝 Two Pair
同為三條
順 勝 三條
同為順
…
同花順勝鐵支
同為同花順
參考答案
2 vs 2, 2 vs 3
10 vs J
K vs A
Diamond 2 vs Diamond 2
Club 2 vs Diamond 2
Heart 2 vs Club2
Spade 2 vs Heart 2
三人相比
四人相比（？）
Player Cards + Board
source code:
28

29. 為什麼我們這麼關心「測項」？
29

30. →
為什麼能安心？需求 文件 + 糾察隊
30

31. https://www.eecs.yorku.ca/~jonathan/publications/2004/xp2004.pdf 31

32. 「測項多多、步驟小小」就是 TDD 了嗎？
32

33. 測試除了保護功能，還要能「支持重構」！
33

34. 為什麼 TDD 時的「重構」這麼重要？
→ 因為我們想要好的「設計」
34

35. Kuma 表示：
開工前的設計也不錯，但「重構」時的設計，是最棒的設計。
因為此時亮的是綠燈，你知道問題已經解決，也已經掌握需求的變化方向了。這個
時候做設計，最不容易做錯事，剛剛好！
35

36. 所以我切小步，做完功能，再重構漂亮，總該是 TDD 了吧？
36

37. 一天十重構
十天一重構
37

38. 為什麼時不時要重構一下？
AI 產的 Code 你要不要檢查？
如果要，那我問你， 20 行的程式你要看多久？
那 2,000 行呢？
那 40,000 行呢？
38

39. 39

40. 你已經「看到」設計的不足了，又有測試保護
此時不除，更待何時？等他長大嗎？
40

41. 友善題：有獎徵答！
41

42. Anthropic 表示
42

43. 從「問題」（不是規格）出發
先確定「我們對問題有共識」
再想辦法「解決問題」
SDD is:
不要解決沒人感到困擾的問題
43

44. 在功能上，永遠只關注一件小事
在設計上，永遠只關心正在發生的變化
情況有變，永遠可以改變計劃
TDD is:
44

45. 今年火速流行的 Specification Driven Development （ SDD ）
是一種「 Form Oriented 」還是「 Context Oriented 」求解方式？
Pop Quiz ！
45

46. - 從「問題」出發去解決問題，不要解決「沒人有困擾」的問題
- 大家都是「 Solution 」的專家，把時間花在有用的事情上
- 用 AI 生成程式或測試沒什麼大問題，但測試能不能表現需求，是你的責任
- 設計好壞見仁見智，但對錯沒得商量！
- …
該做的事沒有變少，你的責任沒有變小，要懂的事也還是這麼多
- 而且 Git 上留的是「你的名字」！
結論：
46

47. Q & A