實作與 Code Review

從一張開發任務開始，到形成可以合併的程式變更

從一張開發任務開始，到形成可以合併的程式變更

實作開始前

  • 確認需求、驗收標準與修改範圍
  • 找到 repo、入口、相關模組與既有慣例
  • 建立可重現的開發環境與必要設定
  • 確認 dependency、資料與外部服務是否可用
  • 建 branch／worktree 與第一個 checkpoint

開發環境與 Repository 結構

  • Runtime、compiler、package manager 與版本
  • Source、test、config、migration、script、docs
  • .env.example、secret 與本機設定
  • Build、run、test、lint 的標準指令
  • README、contributing guide 與 agents.md

Vertical Slice：切一個可驗收的小片段

介面／API 入口
   → 商業規則
   → 資料存取
   → 回傳或畫面
   → 測試與觀測

不要一次把所有 layer 都做完，最後才整合。

寫 Code 時實際在處理什麼？

  • 正常流程與主要資料轉換
  • Input validation 與 domain rule
  • Error handling、exception 與失敗回應
  • Side effect、transaction 與外部服務呼叫
  • Boundary case、null、空資料與重複操作
  • Logging、metrics 與可診斷資訊

Dependency Management

  • 為什麼需要這個 package？有沒有更小的替代方案？
  • Version constraint、lockfile 與 reproducible build
  • Transitive dependency 與供應鏈風險
  • Breaking change、deprecation 與 upgrade path
  • License、維護狀態與已知漏洞

Database Change 與 Migration

  • Schema change 是否 backward compatible？
  • 先 deploy Code 還是先執行 migration？
  • 舊資料如何 backfill、驗證與回復？
  • 長時間 migration 是否鎖表或影響服務？
  • Expand-and-contract 如何支援分階段發布？

自動品質檢查

工具 主要用途
Formatter 統一排版，減少無意義 diff
Linter 找常見錯誤與不一致寫法
Type checker 提前發現型別與介面問題
Static analysis 找資料流、資安與品質風險
Pre-commit hook 在提交前執行基本護欄

Code Review 看什麼？

  • 變更是否真的符合需求與驗收標準？
  • 修改範圍是否合理，有沒有意外影響？
  • 命名、結構與抽象是否能表達意圖？
  • 錯誤、權限、資料與並行情境是否處理？
  • 測試是否能證明行為，而不是只增加覆蓋率？
  • 是否容易部署、觀測與回復？

Review 的工作流程

作者 self-review diff
  → 建立 PR 並說明背景、做法、風險、測試
  → Reviewer 提問或 request changes
  → 作者修改、回覆、重新跑 CI
  → approve → merge

Refactor 與 Feature Change

  • Feature change：改變外顯行為
  • Refactor：維持外顯行為，改善內部結構
  • 兩者混在同一個巨大 diff，會提高 review 風險
  • 先建立 baseline test，再做小步重構
  • 每一步都保持可以執行、測試與回復

什麼叫可以交給下一階段？

  • Acceptance criteria 有對應結果
  • 本機測試、lint、type check 通過
  • Diff 已 self-review，沒有夾帶無關修改
  • Migration、設定、風險與回復方式有說明
  • Commit 與 PR 足以讓下一個人理解脈絡

看到 Agent 寫 Code 時

要能分辨它正在實作 feature、修改 dependency、
執行 migration、處理 review，還是進行 refactor。

產生 Code 很快，控制變更邊界才是工作