鐵人檔案
AI 讓過度設計的產生速度追上了按 Enter 的速度，人眼逐行 review 已經追不上。這系列用一組相同的驗收測試，對照乾淨版本與過度設計版本，示範「測試通過」不等於「設計正確」，並探討 Review 在 AI 時代該審的不再是程式碼本身，而是產生程式碼的規則（測試紀律、架構契約、複雜度預算）。
前言：「有 Retry、有 Transaction,聽起來至少比較安全吧?」 如果你 review 到一段程式碼,類別名稱叫 RetryingArticleRe...
前言：「事件驅動架構,不是為了將來的擴充性嗎?」 「先把事件機制建好,以後要加新功能只要多掛一個 Listener」——這句話你可能自己也講過,聽起來完全合理:...
前言：「Repository 回傳的物件不該直接暴露給外層,這不是常識嗎?」 「Domain 物件不該直接穿過 Application 層,曝露給外層使用」——...
前言：「測試都綠燈了,還要吵什麼設計問題?」 這句話幾乎是每個團隊在 code review 時都會遇到的攔阻論點:PR 附上了測試報告,10 個測試全部通過,...
前言：「花點時間仔細看,總看得完吧?」 面對一個規模較大的 PR,很多團隊的直覺解法是「那就多花點時間、找資深的人仔細看」。這句話背後的假設是:review 的...
前言：「這段程式碼沒有 bug,review 過關,問題在哪?」 Day 11-13 拆解的三個案例(空的 UnitOfWork、假的重試、死碼 DTO),都有...
前言：「這系列講了 16 天問題，到底什麼時候要講解法？」 如果你從 Day 1 一路看到這裡，大概已經受夠「過度設計有多可怕」這件事了——745 個檔案、21...
前言：「這套方法論該不會是你自己發明的吧？」 昨天講完 Outside-In TDD／ATDD 怎麼擋住過度設計，這裡有一個很合理的質疑：這聽起來很像是「先射箭...
前言：「這些規則我早就跟團隊講過了，為什麼還是沒用？」 「依賴要往內指，不能反向依賴」「不要為了假設性的需求先建抽象層」——這些話,只要當過幾年 tech le...
前言：「這個 PR 改了 11 個檔案，很多嗎？」 如果你把一個「文章加一個分類欄位」的需求丟給團隊，PR 開回來改了 11 個檔案，你會核准嗎？大部分 rev...
