最近 code review 的感想
現在team裡很多 PR 一半以上是 AI 生的，一開始心態很鬆，想說邏輯通常沒問題，掃過去就好，後來吃過幾次虧。查到一篇文章掃了 75 份 AI 寫的檔案，81% 都有至少一個真的會出包的問題，數字有點嚇人。整理幾點心得。
- 看起來整齊是沒有用的
AI 捏造不存在的函式還好，程式一跑就報錯，馬上會被抓到。真正麻煩的是跑得動、看起來合理但邏輯是錯的，像很少被觸發的分支，或是用一個過大的 try except 把錯誤整個吞掉，問題藏著不知道哪天爆。AI 寫的命名工整、註解清楚，這種外觀特別容易讓人放鬆警戒直接放行。
- PR 越大，越容易踩雷
AI 寫得又快又多，PR 量比以前大上不少。有看到研究說，抓 bug 能力在改動超過兩三百行後會明顯下滑，改越大大家越懶得認真看。現在看到大 PR 會直接請對方拆小，一個處理一件事，寧願慢一點，也不要讓 review 變成隨便蓋章。
- 留言含糊，AI 也看不懂
以前看到不順眼就丟一句這樣寫不好，沒說明清楚該怎麼改，對方也看不懂。現在改成講原因加建議，例如這個函式做太多事，建議拆開，而不是只丟一句職責太多。多打幾個字，省下的來回次數划算多了。
- 拿自己的寫法當標準，容易誤判
AI 寫出來的風格會跟團隊習慣不完全一樣，有時會讓人忍不住想全部改掉。現在會先問自己，這是會出錯還是我比較喜歡，會出錯才講，只是喜好就放過。
- 不要把 PR 晾著不看
有時候手上事一多就會把 PR 晾著不看，對方卡住，後面工作也跟著卡。AI 產出快，積壓的 PR 會越來越多。現在空出手第一件事先清一輪，哪怕先留句我還要再想想，也比沒反應好。
- 只看 diff 不夠，要主動要求 AI 補上 context
有次改動單看邏輯沒問題就放行，結果上線出事，那段程式碼被呼叫的地方有個隱藏假設，單看 diff 看不出來。AI 只看你給的範圍，有些是專案裡沒寫出來的潛規則，要請 AI 看懂以後再補上 PR。
總結來說，review 這件事技術只佔一半，另一半是溝通與拿捏分寸，對人對 AI 都一樣。現在多了 AI 這個強力幫手，加速了開發速度，但不代表可以偷懶，該花的力氣一點都不能省，反而因為 AI 的出現，產量大增以後 review 的量也需要大量的提升，不能隨便看過就放行，這是身為開發者不能鬆懈的一環。
留言區