Go 測試道地寫法：Table Driven Test
最近在寫 Go 測試時發現官方與社群中有一種大力推崇的慣例：TableDrivenTest，我一直以為測試應該要保持簡單愚蠢，但這種做法讓我想到程式人的三大美德之一：「懶惰」。可能是因為這種模式通常只是測試框架包裝下的方便手段，而 Go 社群文化下人人對於追求簡單程式有一種莫名的執著。
最近在寫 Go 測試時發現官方與社群中有一種大力推崇的慣例：TableDrivenTest，我一直以為測試應該要保持簡單愚蠢，但這種做法讓我想到程式人的三大美德之一：「懶惰」。可能是因為這種模式通常只是測試框架包裝下的方便手段，而 Go 社群文化下人人對於追求簡單程式有一種莫名的執著。
紀錄近期從 JavaScript 遷移到 Go 的過程中實踐 Set 資料結構的方式。先前代碼使用 JavaScript Set 來實現不重複資料定義，但在 Go 語言當中並沒有實踐 Set 資料結構，但我們可以透過改造 map 來實踐。
紀錄使用到其中一項 Go 1.16 的 embed 功能，可以把任何檔案在編譯時就包進去，進而不用煩惱路徑與環境問題。如果資料需要在 runtime 被修改，那就不適合使用 embed，但如果它是「版本的一部分」，那 embed 是更安全的選擇。
P 與 NP 用來描述解決問題的難度所需的時間為：polynomial time 或 non-deterministic polynomial time。將問題分類為 P 或 NP，有助於理解一個問題是否有可能在合理的時間內被解決——即執行時間不會隨著輸入規模的增長而爆炸性膨脹。
先前探討到：什麼是 Feature Flag 以及它解決什麼問題？了解 Feature Flag 存在的價值後，今天了解更多關於 4 種類型的 Feature Flag 以及實戰上的用途。不同目的的 Flag，在設計方式、生命週期、動態程度與管理策略上都有明顯差異。
我一直覺得事情可以保持簡單就好，有問題改程式碼或環境變數切換就好，何必導入更複雜的套件管理與第三方服務呢？但真實情境當問題發生時不會有空閒慢慢部署與除錯，就有必要透過更完善的 Feature Flag 規劃來降低推送功能的風險，也能減少心臟病發作的機率。
通常有些規模的專案會透過架構分層的方式來管理，而近期在研究如何更好的透過「依賴注入」替換模塊並實現更乾淨的測試。架構分層的概念可以參考之前寫過的：Express.js 入門建構 MVC 範例。我上傳了 go-gin-testing-todos 範例透過 DI 實踐測試架構。
從 JavaScript 轉寫 Go 我其實還是不太熟悉 Go 如何模組化處理代碼，雖然它們有大致相似的地方，但使用體驗感覺非常簡單甚至到簡陋的程度，當然簡單並不意味著「容易」或「沒用」，Go 簡單且固執己見的哲學在各方面都感受得到。
很早以前接觸資料庫就有聽說過「N+1 問題」，不過一直沒有寫下筆記認真思考過一次，這次撰寫問題成因與詳細解方與圖表。透過：資料結構設計（去正規化）、在 DB 層完成關聯資料查詢、批次查詢並在應用層組裝、ORM ODM Eager Loading 來解決。
使用 Agentic AI 解決問題時上下文管理至關重要，而 Anthropic 推出的 Agent Skill 上下文管理模式近期也成為業界的一種主流標準，在 Claude Code、Codex、Opencode 等工具中都有支援，透過研究如何整合進入現有的流程來增加開發效率。
處理傳遞資料時都快忘了有「序列化與反序列化資料」這個步驟，因為都被套件像是：Axios 抽象掉了，近期在寫後端也重新溫習相關知識，也延續先前文章：Go Struct Tag 是什麼？如何透過 reflect 動態處理欄位？探討 Go 如何處理序列化資料。
學習高階程式語言通常都會接受一個觀念是：「沒用到的變數會自動被垃圾回收掉」。不過越接近底層或開始探討效能問題，發現自己對於程式語言核心的記憶體概念 Heap 與 Stack 並沒有那麼清楚。程式語言究竟是如何分配與管理記憶體的？所謂的垃圾回收（Garbage Collection, GC）具體來說又做了哪些事情？
Context 是 Go 1.7 添加於標準函式庫的功能。常在存取資料庫或其他服務時會遇到，初步看起來是用於「傳遞取消信號」用途的語法，用於處理 goroutine：背負期限（deadline）、取消信號（cancellation signal）、傳遞請求相關的值（request-scoped values）。
隨著越來越多的軟體推廣與強制雙重因子驗證 2FA，我的手機也裝上了 Google Authenticator，但老實說，很長一段時間我只知道「打開 App → 輸入六位數字」，對於這組數字為什麼會一直變、伺服器又是怎麼驗證的，其實沒有真正了解過。直到最近在測試一些相關登入邏輯才回來補齊這塊知識。
前端測試一直存在龐大的需求，但具體討論如何實戰中建構合理測試體制的討論文章卻不多，隨著社群工具成熟與不同的嘗試下我摸索出一套實戰可採用的方式替團隊建構設施。這篇文章參雜主觀意見與特定的上下文，主要統整近期在工作中的經驗選擇某項解決方案之前必須知道自己選擇的原因以及未來的走向，有太多已經被淘汰的技術與陳舊代碼。