前言

現在寫 Code 的環境真的很幸福。AI 隨便按兩下就能幫忙生出大段程式碼，CI 管線自動跑測試，還有各種靜態掃描工具在背景盯著。

但是，系統架構對不對、商業邏輯有沒有漏洞、資安細節有沒有顧到，這些核心問題還是得靠人腦來把關。

在整個開發流程中，Pull Request 不只是把程式碼合進主線的按鈕。它是團隊互相交流、debug、把關品質的最後防線。我們要確保每一行交出去的 Code 不只跑得動，更要符合業務邏輯且安全無虞。

為什麼一定要做 Code Review？

• 守護系統架構：自動化工具不會去管你寫的 Code 有沒有違反既有的設計模式。透過同事互相 Review，才能避免技術債像雪球一樣越滾越大。

• 擋掉棘手的安全與邏輯漏洞：掃描工具只能抓出常見的死板問題，但如果是商業邏輯上的越權操作，或是資料庫沒處理好的併發問題，真的得靠有經驗的眼睛來盯。

• 打破資訊孤島：透過互相看 Code，大家才能掌握彼此的開發進度。就算哪天某個神隊友請假出事，也不會整組人黑人問號、沒人看得懂他在寫什麼。

PR 到底要怎麼運作才不會吵架？

為了避免大家為了 Review 意見不合、拖慢進度，團隊必須先建立好遊戲規則：

1. 發起人（PR 作者）的自律清單

在丟出 PR 之前，請務必先自己檢查過一遍，不要把沒整理好的東西直接丟給別人收尾：

• 範圍縮小：一個 PR 就好好解一個任務就好。千萬不要順便美化其他 Code，這種「順便」往往是災難的開端。

• 清理噪音：把測試用的 console.log、被註解掉的舊程式碼全部清乾淨。

• 自己先跑過：確保本地的單元測試跟整合測試全部通過，再發上來避免浪費同事的時間。

2. 審查者（Reviewer）該把精神放在哪？

審查別人的 Code 時，要把力氣花在真正重要的地方：

• 別在排版上糾結：排版、縮排、分號這種小事，直接交給 ESLint 或 Prettier 自動搞定。如果工具沒擋到，就去改工具設定，不要在 PR 留言底下爭論這些細節。

• 盯緊效能與架構：檢查有沒有寫出效能很差的查詢（例如迴圈裡面包資料庫查詢這種問題），或是引入了不必要的奇怪依賴。

• 安全第一：確認機敏資料沒有外洩的風險，API 的輸入也必須做好驗證。

3. 用系統綁死分支保護 (Branch Protection Rules)

不要過度依賴人性，直接透過系統工具強制執行規則：

• 強制 Review：設定至少需要一到兩位指定資深同事按下 Approve，這個合併按鈕才能解鎖。

• 綠燈才能合：只要 CI、資安掃描、品質門禁有任何一個項目呈現紅燈，合併按鈕直接鎖死，沒得商量。

團隊到底怎麼放 Code？單一倉庫的優勢

在團隊規模沒有到非常大的情況下，強烈建議採用「單一倉庫、多分支（Single Repo, Multiple Branches）」的模式，而不是讓大家各自 Fork 倉庫。

• 好處在哪裡？：這樣要管理 CI/CD 的 Webhook、集中存放機密金鑰（Secrets）會方便很多，也能利用權限管理精準控制誰可以推 Code 到特定的分支。

結語

程式碼審查是人類智慧在開發流程中的最後一道保險。自動化工具幫助我們追求速度，但人工的 Review 才能確保我們的 Code 走在正確的道路上。

為了讓審查更有效率，PR 的說明文字寫得好不好非常關鍵。在明天的文章中，我們將探討如何打造實用的 PR 模板，讓同事在短時間內就能掌握變更的核心重點。