剛開始參與團隊專案時，我常常會有一種想法：
既然都已經做到這裡了，多完成一些內容，應該會更好吧？
當時的我認為，只要畫面和互動看起來已經足夠完整，多做一些相關內容，應該算是把任務完成得更完整。
直到有一次開 Pull Request（PR），reviewer 提醒我要重新看一次 Issue，我才發現：
在團隊開發裡，做得更多，不一定代表做得更好。
有時候，多做的內容反而代表自己沒有確認清楚任務範圍。
當時我負責的是一張「醫院－搜尋欄切版」的 GitHub Issue。
這張任務的核心，是建立 SearchBar.vue 元件，另外還包含按鈕 active 效果與 RWD 響應式調整。
但在開發過程中，我不只加入了 SearchBar.vue。
同一筆提交裡，我還加了一個簡單的 HospitalView 頁面包裝、/hospital route，以及 Header 和 Sidebar 裡前往醫院頁面的導覽連結。
那時候的我認為，這些內容彼此有關。
既然搜尋欄最後要出現在醫院頁面裡，那把頁面和路由一起補起來，好像也很合理。
完成後，我建立了第一張 PR。
我原本以為自己多完成了一些內容，應該會讓整體看起來更完整。
但 reviewer 看完後，留言提醒我要重新確認 Issue。
留言的大意是：
這張 Issue 的核心是建立
SearchBar.vue元件，要再回頭確認 Issue。
看到這段留言時，我第一個反應其實是緊張。
我擔心的不是搜尋欄有沒有做壞，而是：
我是不是不小心碰到其他組員負責的範圍了？
團隊專案裡，每個人都有自己的任務。
如果修改到其他組員也正在處理的部分，不只可能增加衝突的風險，也可能讓原本的分工變得不清楚。
看到 Review 留言後，我重新打開 Issue，再回頭比對自己的 PR。
這時我才發現，真正需要處理的不是搜尋欄本身，而是：
我的 PR 已經放進了原本 Issue 沒有要求的內容。
原本的任務聚焦在 SearchBar.vue。
但第一張 PR 裡除了搜尋欄之外，還包含：
HospitalView
/hospital route
Header 導覽
Sidebar 導覽
這些修改本身不一定代表程式有問題。
真正讓我開始重新思考的是：
它們是不是應該出現在「這一張」PR 裡？
以前的我會把 Issue 當成一個大方向。
大概知道要做什麼之後，就開始寫程式。
只要畫面有出來、互動也做了，我就很容易覺得：
那應該就算完成了吧？
但這次我才發現，在團隊開發裡，功能做出來只是其中一部分。
還要確認：
我原本以為自己是在「多做一點」。
但站在 Reviewer 的角度，這張 PR 要看的東西反而變多了。
經過這次 Review，我開始重新理解 Issue 的用途。
Issue 不只是功能說明，也可以幫助我們確認這次任務的邊界。
例如這次的 Issue 明確把重點放在：
SearchBar.vue
按鈕 active 效果
RWD 響應式調整
那我在開發時，就應該先把這個範圍完成。
如果一張 PR 同時加入頁面、路由、導覽和其他功能，Reviewer 原本只需要確認一個元件，最後卻必須一起理解更多修改。
修改範圍越大，通常也會增加一些風險：
我也開始建立一個自己的習慣：
盡量讓 Issue、Branch、Commit 和 PR 都對齊同一個任務。
例如這次做的是搜尋欄：
Issue
→ 描述搜尋欄需求
Branch
→ 圍繞搜尋欄命名
Commit
→ 記錄搜尋欄相關修改
PR
→ 說清楚這次完成哪些搜尋欄內容
這樣 Reviewer 才比較容易理解修改目的，也比較容易進行測試和確認。
我後來才明白：
PR 的重點不是放進多少程式碼，而是能不能清楚完成一件事情。
收到 reviewer 的提醒後，我決定重新整理這次修改的範圍。
我先重新建立了一張新的 PR，接著把原本那張 PR 關閉。
在新的 PR 裡，我再提交一次修正，把原本多加入的內容移除：
HospitalView
/hospital route
Header 導覽
Sidebar 導覽
整理完成後，最後留下來的修改只剩下：
SearchBar.vue
search icon
到這時，這張新的 PR 才真正回到原本的任務：
完成搜尋欄的切版與互動狀態。
內容包含：
SearchBar.vue
這裡的搜尋欄還不是完整的醫院搜尋功能。
當時這張 PR 主要處理的是：
畫面切版與元件內的 UI state。
真正的 API、資料查詢、store 與後續完整搜尋流程，並不是這張 PR 的範圍。
重新整理範圍之後，事情也沒有變成：
PR 開出去就結束了。
新的 PR 裡，組員又從其他角度提出建議。
其中一個問題是 Toggle 的點擊範圍。
當時外層使用 label，會造成整行都可以被點擊。
Reviewer 建議把外層調整掉，並在真正可以點擊的按鈕上加入適合的游標提示。
我後來依照建議修正了按鈕的點擊範圍。
另一個 Review 則提醒我：
元件本身不一定要決定自己的最大寬度，可以把這件事情交給父層控制。
所以後來我也移除了搜尋欄元件裡原本設定的寬度上限。
這兩個問題都不是：
程式完全不能跑
但它們會影響：
使用者點擊的體驗
元件未來被其他頁面使用時的彈性
這讓我更明確感覺到：
Code Review 不一定是在找「哪一行寫錯了」。
有時候 Reviewer 注意到的，是開發者自己沒想到的使用情境或元件設計問題。
如果現在重新做一次這張 Issue，我不會只看功能名稱就直接開始開發。
我會先確認：
完成後，我也會重新比對：
Issue
Branch
Commit
PR
確認它們是不是都在描述同一個任務。
現在收到 Issue 後，我會先把需求分成：
這次一定要完成
和：
之後可以再處理
兩部分。
開發過程中如果想到其他相關功能，我也不會直接全部塞進同一張 PR。
我會先把想法記錄下來，再和組員確認是不是需要另外建立 Issue。
這樣不只能避免任務越做越大，也能讓每一張 PR 保持比較清楚的目的。
除了改變自己開 PR 的方式，這次經驗也影響了我後來 Review 組員 PR 時的做法。
輪到我 Review 組員的 PR 時，我通常會先閱讀 Issue 和 PR 說明，再按照內容實際操作功能。
如果修改和畫面有關，我會特別確認不同畫面尺寸下有沒有明顯問題。
程式碼的部分我也會看，只是以我的程度，不一定能在短時間內完全理解每一段程式碼。
這也是我一開始很沒自信的地方。
我會想：
如果我沒有完全看懂這段程式，我真的有資格 Review 別人嗎？
後來我才慢慢發現，Reviewer 不一定只能找很困難的技術問題。
我還是可以去確認：
Issue 和 PR 有沒有對上
功能操作起來是不是合理
畫面有沒有明顯問題
RWD 有沒有跑掉
修改範圍是不是太大
這些事情一樣可能幫助團隊發現問題。
遇到比較不確定的程式碼時，我有時候也會先請 AI 協助整理：
這段修改可能有哪些風險？
有哪些地方值得特別檢查？
Reviewer 可以從哪些方向看？
但我不會直接拿 AI 的回答當成 Review 結論。
我的做法比較像：
AI 幫我整理檢查方向
→ 我回去看 Issue
→ 實際操作畫面
→ 再看程式碼
→ 最後自己判斷
因為 AI 可以幫我找到方向，但不能直接替我決定：
這段程式到底對不對？
最後留下 Review、提出問題或按下 Approve 的人，還是我自己。
當自己的程式被 Review 時，我其實很希望組員幫我找出問題。
因為連自己的程式碼，我有時候都不一定能一次把所有事情看清楚。
多一個人從不同角度確認，就可能發現我自己沒有注意到的地方。
但輪到我要 Review 組員的 PR 時，我反而會擔心：
我的程式能力沒有其他組員好，真的有資格提出問題嗎？
我也會害怕，自己的留言看起來像是在找對方麻煩。
經過這些經驗後，我才慢慢發現：
Code Review 並不是能力競賽，也不是只有程式最厲害的人才能參與。
Reviewer 不一定要找出非常困難的技術問題。
有時候只是：
重新確認 Issue
實際操作一次功能
看看畫面
確認不同尺寸
檢查 PR scope
就可能補上開發者沒有注意到的盲點。
那次 reviewer 提醒我重新看 Issue，也讓我回頭發現：
我的 PR 內容已經超出這張任務原本描述的元件範圍。
後來新的 PR 又有人提醒我 Toggle 點擊範圍與元件寬度的問題。
我後來也不再把這些留言理解成是在否定我做的內容。
我開始把它看成：
在程式真正合併以前，多一個人從不同角度幫我確認，還有沒有自己沒注意到的地方。
我希望別人能幫我找到自己的盲點，也開始學著用同樣的方式，替組員多確認一次。
這就是我開始理解 Code Review 價值的時候。
經過這次 Code Review，我開始理解，團隊協作不只是把自己的功能完成，還要讓自己的修改能順利和團隊其他人的內容整合。
但當不同組員同時修改相同檔案時，Git 不一定能自動判斷要保留哪一邊。
下一篇：
Day 22｜合併衝突！我第一次和 Git 打起來。
iThome鐵人賽
看影片追技術