
在 Game Jam(黑客松)寫測試有用嗎?
在遊戲開發中寫測試一直以來都是被認為相當困難的一件事情,雖然有很多人嘗試,但我們仍沒有找到一個很好的方法解決。
同時,寫測試對許多人來說是一種拖慢開發速度的工作,這次我在每年都會參加 Global Game Jam 中挑戰用 48 小時的時間開發,運用這段時間學到的 Domain-Driven Design(領域驅動設計)、Clean Architecture(清楚架構)、敏捷開發、ATDD(驗收測試驅動開發)等技巧來做實驗。
在遊戲開發中寫測試一直以來都是被認為相當困難的一件事情,雖然有很多人嘗試,但我們仍沒有找到一個很好的方法解決。
同時,寫測試對許多人來說是一種拖慢開發速度的工作,這次我在每年都會參加 Global Game Jam 中挑戰用 48 小時的時間開發,運用這段時間學到的 Domain-Driven Design(領域驅動設計)、Clean Architecture(清楚架構)、敏捷開發、ATDD(驗收測試驅動開發)等技巧來做實驗。
最近在實作一個會員集點功能的時候意外發現很適合作為「領域事件(Domain Event)」的例子,在很多情況下其實不容易去描述這個概念,然而這個例子倒是很好的反應這個概念,以及 Rails 的特性所產生的變化。
之前在查資料時,在 Twitter 上看到 DHH 對 DCI (Data Context Interaction) 的看法同時上週的我對 Domain-Driven Design 的理解(2022 年)這篇文章也提到了 DDD 跟 DCI 不互斥,而且能夠改善某些設計上的問題。
因為把 Domain-Driven Design: The First 15 years 看完後腦中有了非常多想法,為了不要太快把這些東西忘記,只能盡快寫成文章記錄下來。
簡單來說,我認為 Domain-Driven Design 是一種「觀念」而不是理論或者實踐,他更接近於將「模型(Model)」的概念帶入到程式設計中,也因此在書中提到 Domain-Driven Design 是沒有嚴格規定,只有接近跟遠離核心的差異。