從混亂到優雅，讓專案不再失控：ATDD 與 Clean Architecture 的後端實戰之路

你是不是也遇過這種情況？每當專案多一個新功能，整個系統就像被隕石砸到一樣，到處都是坑，永遠補不完。這次很高興能和我實習的同事 Dong 一起在 COSCUP 中，向大家分享，我們是怎麼從「隕石式開發」走到擁抱 ATDD 和 Clean Architecture。

Transcript

1. 從混亂到優雅 讓專案不再失控 ATDD 與 Clean Arch 的後端實戰之路 @dongdong867 @an920107
2. 東東 dongdong867 # Experience iOS Intern @LINE Tech Lead/ Full Stack Dev @OpenNCCU # Education Master/ Bachelor of MIS @NCCU
3. Squire an920107 # Experience Android Intern @LINE CTO @AIlicorn # Education Master/ Bachelor of CSIE @NCU
4. 一切的混亂是怎麼開始的 ?
5. 在這邊隆重介紹 你可以不嘗試, 但一定要推薦你的工程師朋友試試看 隕石式開發
6. 我們需要一個酷酷的新功能 Customer 感覺可以跟以前的 XXX 功能整合 PM/ PjO 明天~ PM/ PjO Dev 什麼時候要 ? Dev
7. 加了新功能之後, XXX 功能壞了 QA 改完之後換 OOO 功能壞掉了 QA Dev @all 剛剛推新功能上 beta 了 Dev 改完了, 已經推 hotfix 了 Dev ???
8. 後院天天起火 把每次修改都搞的像在開發新功能 改 A 壞 B, 修 C 壞 D
9. 我們是怎麼走到這一步的 ?
10. 我們是怎麼走到這一步的 ? 技術債 + 屎山程式碼 + 以後會補的測試 + #@)%&*#(@⋯⋯!(
11. 我們是怎麼走到這一步的 ? 技術債 + 屎山程式碼 + 以後會補的測試 + #@)%&*#(@⋯⋯!( Independence/ Expendability Maintainability/ Testability
12. How clean is enough to call it clean code How much test is enough for a test
13. 當測試成為開發的核心與團隊間的共同語言
14. Acceptance test–driven development 驗收測試驅動開發 ATDD
15. 驗收測試驅動開發 ATDD 先畫靶, 再射箭 不只是測試, 而是一種協做方法 從使用者出發, enough is enough 透過統一切規範的格式, 明確定義功能的最小可接受行為
16. 好的 我知道 ATDD 很棒了 那我現在要怎麼開始使用 ATDD
17. Gherkin Syntax Given - When - And - Then
18. Gherkin Syntax 用人話簡單易懂的解釋程式預期的行為 推進溝通並在 domain expert 與 non-domain expert 之間取得共識
19. Gherkin Syntax Feature: 登入 As a 使用者 I want to 登入系統 So that 我可以使用系統內的功能 Scenario: 登入失敗三次後帳號鎖定 Given 進入登入頁面 And 已經登入失敗兩次 When 輸入正確使用者帳號跟錯誤的密碼 And 點擊登入按鈕 Then 接收到帳號被鎖定的訊息
20. Gherkin Syntax Feature: 登入 As a 使用者 I want to 登入系統 So that 我可以使用系統內的功能 好多字, 好懶, 不想看 Scenario: 登入失敗三次後帳號鎖定 Given 進入登入頁面 And 已經登入失敗兩次 When 輸入正確使用者帳號跟錯誤的密碼 And 點擊登入按鈕 Then 接收到帳號被鎖定的訊息
21. Scenario: 登入失敗三次後帳號鎖定 Given 進入登入頁面 And 已經登入失敗兩次 When 輸入正確使用者帳號跟錯誤的密碼 And 點擊登入按鈕 Then 接收到帳號被鎖定的訊息 Gherkin Syntax Feature: 登入 As a 使用者 I want to 登入系統 So that 我可以使用系統內的功能 好多字, 好懶, 不想看 出口在您的右手邊, 慢走不送
22. Flow chart 化驗收情境 用一條分支代表一個 test case
23. Flow chart 化驗收情境 登入功能 輸入帳號密碼正確 輸入帳號密碼錯誤 登入成功 錯誤次數 < 3 次 登入失敗 錯誤次數 ≥ 3 次 登入失敗 帳號鎖定
24. Flow chart 化驗收情境 登入功能 輸入帳號密碼正確 輸入帳號密碼錯誤 登入成功 錯誤次數 < 3 次 登入失敗 錯誤次數 ≥ 3 次 登入失敗 帳號鎖定 􀁣
25. API Route User Entity Post Entity Login UseCase Create Post UseCase Get Recommendation UseCase Firebase Service DB Service
26. API Route User Entity Post Entity Login UseCase Create Post UseCase Get Recommendation UseCase Firebase Service DB Service
27. API Route User Entity Post Entity Login UseCase Create Post UseCase Get Recommendation UseCase Firebase Service DB Service
28. Repository Impl Repository Use Case Trait 調用 實現
29. Repository Impl DB Service Impl Repository Use Case Trait DB Service Trait 內層 外層 依 賴
30. Clean Architecture 究竟能為我們帶來什麼？ 業務邏輯不再被任何框架或資料庫綁架 Entity Use Case Gateway ＭongoDB PostgreSQL MySQL ...... Controller API Route
31. Clean Architecture 究竟能為我們帶來什麼？ 抽象介面帶來極致的可測試性 Mock Repository Repository Use Case Trait
32. API Route User Entity Post Entity Login UseCase Create Post UseCase Get Recommendation UseCase Firebase Service DB Service
33. How clean is enough to call it clean code How much test is enough for a test
34. API Route User Entity Post Entity Login UseCase Create Post UseCase Get Recommendation UseCase Firebase Service DB Service
35. API Route User Entity Post Entity Login UseCase Create Post UseCase Get Recommendation UseCase Firebase Service DB Service
36. 為什麼我們需要 clean code
37. 為什麼我們需要 clean code As is: 使用者登入 → 在 DB 寫入 user.is_online = true 好友頁面中 → 從 DB 讀取 user.is_online 並顯示在 UI 上
38. 為什麼我們需要 clean code As is: To be: 使用者登入 → 在 DB 寫入 user.is_online = true → DB 中的 user.is_online (bool) 欄位變更成 user.status (enum) 好友頁面中 → 從 DB 讀取 user.is_online 並顯示在 UI 上 好友頁面中 → 從 DB 讀取 user.status 並顯示在 UI 上 PM: 我們需要一個請勿打擾的狀態
39. 為什麼我們需要 clean code As is: To be: 使用者登入後 → 在 DB 寫入 user.is_online = true → DB 中的 user.is_online 欄位 rename 成 user.status 好友頁面中 → 從 DB 讀取 user.is_online 並顯示在 UI 上 好友頁面中 → 從 DB 讀取 user.status 並顯示在 UI 上 PM: 我們需要一個請勿打擾的狀態 收工 ! 下班回家
40. Clean Architecture 最高守則： 依賴關係都必須指向「內部」 UI External Interface Web Device Controller Gateway Presenter Domain Use Case DB
41. Framework - Web API Route POST /api/article { “content”: “Hello” } RESPONSE 201 { “id”: 1 } 後端與外部互動的進入點 Entity Use Case Gateway Database Controller API Route
42. Adapter - Controller & DTO JSON <-> DTO <-> Entity create_article_use_case() 處理請求的中間轉譯層 Entity Use Case Gateway Database Controller API Route
43. Application - Use Case 每個 Use Case 都代表 App 的一個功能 @ Create Article Use CasD @ Get All Articles Use CasD @ Get Article By ID Use CasD @ Update Article Use Case Entity Use Case Gateway Database Controller API Route
44. Application - Use Case 封裝並執行 App 的業務邏輯 article_repo.create() Entity Use Case Gateway Database Controller API Route
45. Domain - Entity 核心業務邏輯和資料結構 struct Article { content: String } validate() { content != “” } Entity Use Case Gateway Database Controller API Route
46. Adapter - Gateway & Mapper 處理資料調用的中間轉譯層 Record <-> Mapper <-> Entity article_db.create() Entity Use Case Gateway Database Controller API Route
47. Framework - Database & Record 處理資料存儲相關的細節 INSERT INTO article (content) RETURNING id Entity Use Case Gateway Database Controller API Route
48. 但這樣的依賴方向對嗎？ 最高守則： 依賴關係都必須指向「內部」 Entity Use Case Gateway Database Controller API Route
49. 依賴反轉 Dependency Inversion Entity Use Case Gateway Database Controller API Route 定義抽象介面 維持由外而內的依賴關係
50. 依賴反轉 Dependency Inversion Entity Use Case Trait Gateway Database Controller API Route Trait 定義抽象介面 維持由外而內的依賴關係
51. Clean Architecture 究竟能為我們帶來什麼？ 專案結構有了明確的規範，任何人都能快速理解 Domain Application Framework Adapter