測驗：Code Review 與協作技巧
共 5 題，點選答案後會立即顯示結果
1. Code Review 的主要目的是什麼？
2. GitHub Review 中，「Request Changes」代表什麼意思？
3. 在 GitHub 的「Files changed」分頁中，紅色的行代表什麼？
4. 當審查者給出 Request Changes 後，開發者應該怎麼做？
5. 以下哪項是審查者（Reviewer）應該避免的行為？
一句話說明
Code Review 是團隊成員互相檢查代碼，確保品質後才合併。
前置知識
- 第 1-2 篇：GitHub Flow 概念與 PR 建立
- 基本 Git 操作
Code Review 是什麼？
當你建立 Pull Request 後，通常不會直接合併。團隊會先「審查」你的代碼，這個過程就是 Code Review。
開發者 A 開發者 B（審查者）
| |
|-- 建立 PR --------------->|
| |-- 看代碼
| |-- 留言問問題
|<-- 收到 Review 意見 ------|
| |
|-- 修改代碼 ------------->|
|-- 回覆留言 ------------->|
| |-- 確認 OK
| |-- Approve
| |
|-------- 合併 PR ---------|
Code language: HTML, XML (xml)翻譯：Code Review 就像文章發表前請人幫忙看一遍，抓錯字、提建議。
GitHub Review 三種結果
當審查者看完你的 PR 後，會給出三種結果之一：
| 結果 | 圖示 | 意思 |
|---|---|---|
| Comment | 💬 | 「我有一些想法，但不阻擋合併」 |
| Approve | ✅ | 「看過了，可以合併」 |
| Request Changes | ❌ | 「這裡有問題，改完再合併」 |
最小範例：審查者的操作畫面
1. 進入 PR 頁面
2. 點選「Files changed」分頁
3. 看完代碼後，點右上角「Review changes」
4. 選擇一種結果 → 送出
翻譯：
- Comment：「我看了，有些想法分享」
- Approve：「沒問題，請合併」
- Request Changes：「有問題，先改」
如何審查別人的 PR
第一步：看 PR 描述
## 這個 PR 做了什麼
- 新增登入功能
- 修復密碼驗證 bug
## 測試方式
- 執行 npm test
- 手動測試登入流程
Code language: PHP (php)檢查點：
- [ ] 知道這個 PR 要解決什麼問題嗎？
- [ ] 有說明怎麼測試嗎？
第二步：看改了哪些檔案
GitHub 的「Files changed」會顯示所有修改：
# 紅色 = 刪除的行
- const oldCode = "舊的";
# 綠色 = 新增的行
+ const newCode = "新的";
Code language: PHP (php)翻譯：紅色是「拿掉的」，綠色是「加上的」。
第三步：留言提問或建議
在任何一行代碼旁邊，點「+」號就可以留言：
位置：src/login.js 第 42 行
💬 你的留言：
這裡如果密碼是空的會怎樣？
要不要加個檢查？
留言的常見類型
| 類型 | 範例 | 用途 |
|---|---|---|
| 疑問 | 「這行是做什麼的？」 | 不懂的地方 |
| 建議 | 「這裡可以改成 xxx」 | 有更好的寫法 |
| 問題 | 「這裡會不會出錯？」 | 發現潛在 bug |
| 讚美 | 「這個寫法很棒！」 | 鼓勵隊友 |
留言小技巧
# 用 suggestion 提供修改建議
# 開發者可以一鍵採用
Code language: PHP (php)翻譯：GitHub 有特殊語法，讓你直接建議改成什麼，對方可以一鍵接受。
如何回應 Review 意見
當別人審查你的 PR 後，你會收到通知。回應的方式：
1. 如果同意建議
做法一：直接接受 suggestion（如果有的話）
做法二：自己改代碼 → commit → push
修改後在留言下回覆：
已修改，請再看一下 👍
2. 如果不同意
先解釋你的想法：
這裡我是故意這樣寫的，因為 xxx。
你覺得這樣 OK 嗎？
關鍵：不是吵架，是討論。
3. 修改完成後
1. 在對話串回覆「已修改」
2. 點「Resolve conversation」（解決對話）
3. 等待審查者再次 Review
常見 Review 情境
情境 1：審查者 Request Changes
狀態：❌ Changes requested
你要做的事：
1. 看審查者的留言
2. 修改代碼
3. push 到同一個 branch
4. 回覆留言說「已修改」
5. 等待審查者 Approve
翻譯：他說有問題，你改完再請他看一次。
情境 2：有多個審查者
狀態：
- 審查者 A：✅ Approved
- 審查者 B：❌ Changes requested
你要做的事：
- 通常要等所有人都 Approve 才能合併
- 或依團隊規則（例如：2 人 Approve 即可）
情境 3：審查者只是 Comment
狀態：💬 Commented（沒有 Approve 也沒有 Request Changes）
這代表：
- 他有一些想法，但不阻擋合併
- 你可以決定要不要採納
- 通常還是需要找人正式 Approve
團隊協作最佳實踐
對於審查者（Reviewer）
✅ 該做的：
- 快速回應（不要讓人等太久）
- 說明「為什麼」不只是說「不好」
- 如果只是風格問題，用 Comment 而非 Request Changes
❌ 不該做的：
- 批評人而非代碼（「你怎麼會這樣寫」）
- 吹毛求疵每個小細節
- 拖很久不 Review
對於開發者（Author）
✅ 該做的：
- PR 不要太大（小 PR 容易 Review）
- 寫清楚 PR 描述
- 禮貌回應每個留言
❌ 不該做的：
- 無視 Review 意見直接合併
- 覺得被針對（他是在幫你）
- 一次改太多東西
Vibe Coder 檢查點
審查別人的 PR 時確認：
- [ ] 我知道這個 PR 要解決什麼問題嗎？
- [ ] 代碼邏輯有沒有明顯錯誤？
- [ ] 有不懂的地方就問，不要假裝看懂
被審查時確認：
- [ ] 每個留言都有回應了嗎？
- [ ] 修改都 push 了嗎？
- [ ] Conversation 都 Resolve 了嗎？
總結
| 角色 | 主要任務 |
|---|---|
| 審查者 | 看代碼 → 留言 → Approve/Request Changes |
| 開發者 | 收到意見 → 修改/討論 → 等待 Approve |
Code Review 的核心是「互相幫忙讓代碼變更好」，不是「找碴」。
下一篇我們將學習如何處理合併衝突。
進階測驗：Code Review 與協作技巧
測驗目標：驗證你是否能在實際情境中應用所學。
共 5 題，包含情境題與錯誤診斷題。
共 5 題，包含情境題與錯誤診斷題。
1. 審查 PR 時的優先順序 情境題
你是團隊的資深開發者，收到一個新人的 PR 請求 Review。這個 PR 有 500 行代碼修改，涉及 15 個檔案，PR 描述只寫了「修復 bug」三個字。你應該如何處理？
2. 多審查者情境處理 情境題
你的 PR 目前狀態如下：
– 審查者 A：Approved
– 審查者 B：Request Changes（指出一個變數命名不清楚）
– 審查者 C：Comment（建議可以加個註解，但說不阻擋合併）
你應該怎麼做？
3. Review 留言分析 錯誤診斷
審查者在你的 PR 留了以下留言：
「你怎麼會寫出這種代碼？這根本不是專業程式設計師該有的水準。」
這個留言有什麼問題？
4. 處理不同意的 Review 意見 情境題
審查者在你的 PR 留言說：「這裡應該用 forEach 而不是 for 迴圈」。但你認為在這個情況下 for 迴圈效能更好，而且需要用到 break。你應該怎麼回應？
5. PR 合併前的檢查 錯誤診斷
你完成了所有 Review 意見的處理，但合併按鈕仍然是灰色不能點。你檢查了以下狀態：
– 審查者 A：Approved
– 審查者 B：Commented (3 天前的留言)
– CI 測試：通過
– 所有 Conversation：已 Resolve
最可能的原因是什麼？