程式碼審查（Code Review）是透過檢視實際修改，理解目的、影響與取捨，找出需要討論或調整的地方。審查具體會用不同的方法進行，常見的做法例如：配對開發，或是透過 PR 請其他人審查程式。
配對開發（Pair Programming）由兩位開發者一起處理同一份程式，透過共同撰寫、檢視與討論，確認實作是否符合需求。
透過 PR 審查時，大多數系統都會提供程式差異，提交者則補上修改目的與相關說明，讓審查者閱讀並提出意見。雙方透過留言與回覆討論需要調整的地方，並留下決定與理由。
我過去在 Agile 與 CI 之間的火花一文中，曾把配對開發與 Pull Request 放在程式碼審查之下介紹。從廣義來看，上述兩種做法，都屬於程式碼審查。配對開發讓兩人同步檢視與討論；PR 則讓審查者可以在自由的時間閱讀與回覆，以非同步的方式完成審查。
無論採用哪種審查方式，都需要預留討論與回應的時間，避免程式準備好後，還一直等不到審查意見。
下圖依開發中與合併前呈現主流程，旁邊的註記列出可以採用的審查方式。
兩種審查方式可以依需要選用或搭配。合併前要確認準備整合的程式已完成必要審查與驗證；若仍需修改，就調整程式並重新確認。
以下沿用 Kevin 調整前端共用模組的假想情境，說明團隊如何安排這些討論與審查。
Kevin 調整與 Phoebe 共用的模組時，需要留意是否會影響她的介面。兩人可以安排配對開發，一起調整模組與測試。Kevin 撰寫時，Phoebe 同時檢視程式是否保留必要行為，發現問題就當場討論與調整，不必等到程式寫好才取得審查意見。
這種審查隨著程式撰寫持續進行，需要安排兩人都有空的時間。討論過的決定與理由也要留下紀錄，讓後續閱讀程式的人知道當時考量了什麼。
團隊若要求另外取得獨立核准，或由特定模組的維護者審查，仍要完成這些步驟。
假設 Kevin 與 Elvina 已確認，她需要的模組可以分開驗證，不必等待其他尚未完成的程式。Kevin 在提出 PR 前，先自行審查程式差異，排除無關變更與明顯錯誤、補足遺漏的測試，並確認符合團隊規範，再完成本機驗證。
Kevin 在 PR 中說明修改目的、Elvina 需要的新行為，以及原有呼叫端依賴的既有行為，並列出驗證項目、結果與尚未完成的項目。
Phoebe 先確認修改目的與影響範圍，再檢視模組分工、呼叫關係、程式邏輯與測試，確認新行為符合需求、既有行為受到保留，最後檢查命名與寫法。若程式差異不足以判斷，就查看相關程式；需求不清楚時，則找 Kevin 與 Elvina 確認。
Kevin 提出 PR 後，如果一直等不到 Phoebe 的意見，後續修正與整合就可能延後。Phoebe 如果正在專注修改程式，可以等手上的開發告一段落，再處理等待中的審查，之後才開始下一項任務，讓審查與開發都能持續進行。
如果當下無法完成審查，Phoebe 可以先告訴 Kevin 預計何時能提供意見，並留出實際閱讀與確認的時間。若她無法在預計合併 PR 前完成審查，就協助找其他適合的成員。先回覆安排能讓 Kevin 知道要等多久，但仍要完成程式審查，才能判斷是否可以核准。
開始審查後，如果 Phoebe 發現 PR 太大，無法在合理時間內看完，可以與 Kevin 確認是否能拆成幾個各自可驗證的步驟。若暫時無法拆開，她也可以先針對整體設計提出意見，說明主要疑慮，讓 Kevin 知道下一步要處理什麼，不必一直等到整份審查完成才取得回饋。
為了避免審查標準不一致，團隊需要先定義共用標準，區分意見的處理要求及是否影響合併，例如 MUST、SHOULD、MAY：
| 層級 | 處理期待 |
|---|---|
| MUST：必須修正 | 影響正確性或違反明確底線，處理完成前不能合併。 |
| SHOULD：建議修正 | 有具體的品質或維護理由；若不採用，需要說明理由並確認取捨。 |
| MAY：可選建議 | 屬於可討論的偏好或替代做法，不因未採用而阻止合併。 |
層級要依實際影響與團隊約定判斷，不能只看問題類型就決定。
例如，Phoebe 發現測試只確認 Elvina 需要的新行為，卻漏掉 PR 說明中列出必須保留的既有行為。這會影響對既有功能的判斷，可以標為 MUST，請 Kevin 在合併前補上必要測試。
若 Kevin 的命名符合團隊規則，也不影響理解，Phoebe 偏好的另一種命名就屬於 MAY。若命名違反團隊規則，則應指出違反的規則，依約定判定層級。
不影響這次模組調整正確性與維護的舊問題，可以另行安排，避免擴大這次 PR 的範圍。
除了標示層級，Phoebe 還需要指出問題在哪裡、依據是什麼、不處理會影響哪些行為，以及建議如何調整。例如，要求補測試時，除了寫「請補測試」，還要指出漏掉哪個既有行為，以及需要確認什麼結果。
留下意見前，Phoebe 也可以整理重複的發現。同一個原因造成的問題，集中說明受影響的位置與處理方式，避免分散成多則意思相近的留言。需要更多背景才能判斷的部分，則先提出待確認的問題。
Kevin 對某項意見有疑問時，先和 Phoebe 對照需求、既有規則與實際程式。如果留言一直無法釐清，就一起討論；若討論後仍無法取得共識，就依團隊約定，請相關程式的維護者或技術負責人協助判斷。做出決定後，再把決定及理由寫回 PR。確定可以延後的改善，另行記錄範圍與後續安排，讓它成為可追蹤的事項。
Kevin 依意見調整程式與測試後，重新執行受影響的驗證，並在 PR 說明這一輪處理了哪些問題，請 Phoebe 再次確認。Phoebe 對照最新差異與處理結果，確認必要意見已處理，再核准準備整合的程式。
如果還有必要驗證尚未完成，或結果失敗，Kevin 就先完成驗證或處理問題，更新結果後再請 Phoebe 確認。若主幹在審查期間有新的提交，他也要驗證程式與更新後主幹的組合；影響先前審查判斷的部分，再請 Phoebe 檢視。
完成必要審查與驗證後，Kevin 才合併 PR，並確認主幹的驗證結果。驗證尚未完成時等待結果；失敗時通知團隊，修復問題或還原變更，再重新驗證。主幹驗證通過後，Elvina 就能取得所需模組，再驗證它與自己程式的組合。
配對開發讓問題在撰寫時就能被討論；合併前的 PR 審查則需要安排回應時間，並依共用標準標示意見層級，說明判斷依據與處理方式。這些做法都要讓開發者理解修改目的、確認實際程式，並知道還有哪些問題需要處理。
另外，除了上述兩種方式，團隊審查會議也是早期就有的審查做法，由多人面對面檢視與討論程式，當場提出問題並記錄審查結果。
配對開發也有相關的練習與延伸方式：Coding Dojo 的 Randori 形式讓團隊在同一個空間輪流配對，透過共同練習與檢視程式互相學習；Mob Programming 則將兩人的配對擴展為多人同步協作，由一人操作電腦，其他人一起思考、討論與檢視同一份程式。
iThome鐵人賽
看影片追技術