昨天聊了 MCP Server。今天要聊的是貫穿整個開發過程的一個習慣：Code Review。
針對已經寫好的模組，系統性檢查「需求文件寫的行為」跟「程式碼實際的行為」有沒有落差，找出會導致錯誤結果、資料錯誤、或安全問題的具體發現，不是找風格上的意見。執行方式是把模組分別派給獨立的審查任務，每個都附上同一套指示——只報告真正會出錯的地方，不要硬找碴，沒問題的地方不用勉強挑毛病。發現的問題彙整成一份追蹤清單，按風險高低分類，逐一修復、逐一打勾。
基本上會在每個模組開發完畢後，都執行一次 code review——就像需求文件是照模組分開寫的一樣，每個模組也都被當成一次獨立的開發階段，做完就檢查一次，不會累積到最後才一次全部審查。
「不要吹毛求疵」這個指示，是之前 review 過幾次之後累積下來的心得：只要給 agent 明確的方向（例如程式資安、流程邏輯性），讓它照這個方向去審查就好，不需要連風格上的小地方都要求它挑出來講。
負責遮罩敏感資訊的那段邏輯本身完全正確：走過一個物件，只要欄位名稱命中 api_key、token、secret 這類關鍵字，就把值換成 [REDACTED]，連巢狀物件、陣列都處理得到，而且這段邏輯自己的單元測試也一直都是通過的。
問題出在唯一呼叫它的地方：上游服務回傳錯誤時，原本的寫法是把整段回應內容直接塞進一個錯誤訊息字串裡，再拿這個字串去做遮罩。但遮罩邏輯是靠「比對物件的欄位名稱」來判斷要不要蓋掉，一旦內容被打平成一整串文字，欄位名稱這個線索就消失了——不管字串裡面藏了什麼，遮罩機制連看都不會多看一眼。
這個案例的重點在於：一個安全機制對不對，不能只看它自己的測試過了沒有，還要往回追它實際被呼叫的地方，餵給它的到底是不是它原本設計時假設的那種資料形狀。修法也不是讓遮罩邏輯變得更聰明去解析字串，而是從源頭不要把結構打平，讓原本的假設重新成立。
Code Review 在這個專案裡不是收尾才做一次的動作，而是每個模組開發完就做一次的固定習慣。有需求文件當對照，review 才有明確的「對錯」可言；明講「不要吹毛求疵」，則是讓 review 的力氣花在真正重要的地方，而不是湊出一堆風格意見。而遮罩防禦被繞過這個案例也提醒了一件事：測試過的程式碼不代表沒有破洞，破洞常常藏在「呼叫它的地方，給的東西跟它原本設想的不一樣」。
目前專案的分享也告一段落了，明天也是本系列的最後一天，會著重在參賽心得紀錄，感謝大家的觀看!
如果大家看到這邊對這個專案有興趣，完整程式碼都已經整理並開源在 GitHub 上：
iThome鐵人賽
看影片追技術