資深工程師如何把關 Code Review?

先前我們曾寫過 為什麼要 Code Review? 如何做 Code Review? ，以及 為團隊建立更好的 Code Review 原則與規範 兩篇文章來談 Code Review。

從職級的角度來看，第一篇文章主要是寫給初中階工程師，因為在初中階段，工程師主要職責是參與 Code Review。而第二篇的主要受眾則是資深工程師，因為資深工程師影響力擴及團隊的標準與規範。

在這篇文章中，我們會延續資深工程師的視角來談「以打造制度與文化的角度來看，資深工程師可以如何把關團隊的 Code Review」。換句話說，不能只是自己做好審查別人的程式碼，而是要讓團隊整體的 Code Review 品質都能提升。

如果有意面試資深，或者資深以上 (例如主任工程師) 職位的讀者，可以特別留意這篇文章談的觀點 (備註：如果你是初中階工程師，則推薦可以看 [線上課程] 寫出好維護的程式碼 (上) — 經典的程式設計觀點 線上課，該課程協助建立審查他人程式碼時可以用的技術觀點)。

資深以上的工程師如何看 Code Review

過去我們有收到一些讀者詢問，談到自己所在的團隊沒有 Code Review 的機制。從資深工程師的角度來談，這不是個問題，反而是個機會。假如你所在的團隊還沒有 Code Review 制度，從自己做起來導入，才能彰顯資深工程師的價值。甚至假如你的職稱還不是資深工程師，假如你能有效在團隊中導入 Code Review 機制，在找下份工作時，把這點寫在履歷上也能用來佐證自己有做資深層級任務的能力。

更進一步說，資深工程師可以透過 Code Review 來消除團隊的巴士因子(bus factor)。巴士因子是用「假如團隊中最重要的人被巴士撞傷無法工作，這個團隊是否還能繼續如期運作」這個問題來評估團隊的整體健全度。如果因為某個關鍵人物無法工作，就導致團隊無法運作，那代表團隊有單點脆弱性問題；反之，一個健全的團隊，應該要做到不論誰臨時無法繼續工作，團隊也能如期運作。

從表面來看，Code Review 是在把關品質，但除了這點外，Code Review 承擔的更大責任，是傳遞知識，包含讓團隊中的新成員、資淺的成員，能從中學習如何維護團隊的程式碼庫，從團隊所使用的程式碼風格，到如何寫出健康好維護的程式碼，都是在 Code Review 時可以傳遞的。因此把 Code Review 當成一個傳授指導的過程 (mentorship process)，會是資深工程師的重要責任。

除了知識面外，Code Review 有助於形塑與加強團隊文化。Code Review 的過程本身就是一種溝通，在溝通時可能會有各類不同的摩擦、可能有人會有不恰當的言辭、可能有人會用消極被動的方式回應，這些不同的做法，如果在 Code Review 的過程中被默許，就會漸漸成為團隊文化中的一部分。

因此，從資深工程師的角度來看，當某些可能導致文化劣化的行為出現，就需要第一時間去制止與協調，確保相關問題不會再出現，以免團隊的文化變糟。

資深工程師應該要把關什麼?

上一段落談了從資深工程師的角度看，在 Code Review 的過程中，要去把關團隊的文化，以下我們會談五個推薦資深工程師要把關的面向。假如你發現你所在的團隊有類似的問題，務必要主動跳出來協助改善。

假如你未來有打算面試資深工程師 (或資深以上) 的職位，在行為面試中，談到這些守護團隊文化層級的行為，也會比較能讓面試官看到資深該有的訊號。

不要讓低門檻的文化得逞

在許多團隊中，即使有資深工程師把關，仍可能讓不健康的程式碼被合併到主要分支中，成為程式碼庫的技術債。往往這種狀況發生在團隊有些「低門檻」的審查員 (reviewer)，他們會用比較低的標準看程式碼，所以即使程式碼寫得不理想，仍會讓 PR 通過 (下面這個搞笑影片，在某些團隊是真實存在的)。

當團隊中的其他人發現這類低門檻審查員後，很可能為了讓自己的 PR 快速被通過，所以每次都找那些低門檻審查員幫忙看。但這樣的後果，就是參差不齊的程式碼被合併。這也是為什麼，社群中有流傳「你的程式碼庫品質，取決於團隊中最弱的審查者 Your code is only as good as your weakest reviewer」這麼一句話。

因此身為團隊中的資深工程師，假如看到某個 PR 明明沒有到達標準卻被通過，務必要在團隊的會議中提出來討論，並讓團隊成員了解這件事不應該發生。

更進一步，身為資深工程師可以明確地把標準訂定下來。就像先前有分享過的 Google 公開分享的程式碼風格指南，有明確列出不同語言的程式碼應該要怎麼寫。又或者在 [線上課程] 寫出好維護的程式碼 (上) — 經典的程式設計觀點 線上課程中有談到的原則，也可以明確放到團隊的指南當中。

不要讓情緒性攻擊的文化得逞

前面談到，Code Review 本身是一個溝通的過程，而溝通方式會影響團隊的動態與氛圍；不理想的溝通方式，甚至可能會讓團隊成員想要離開。

在軟體業界，不乏聽過有人會在 Code Review 時留下「你這是什麼垃圾程式碼」或是「不要把這種糞程式碼加到我們的程式碼庫中」這類的言論。身為資深工程師，如果看到這種可能帶給團隊負向氛圍的留言，要第一時間跳出來制止，點出這可能帶給其他成員情緒負擔，是把關的重點之一。

特別注意，同樣是造成人不舒服的感覺，有建設性的點評會是良藥苦口，而純粹情緒字眼的批評，則是既苦口又無效。一個運作健康的團隊，應該要有辦法用良好的語氣來維持高標準，這兩者本身不是互斥的；如果程式碼寫得不好，可以用客觀且友善的語氣點出問題。

事實上，一個健康的團隊應該要反過來，不僅不會讓在 Code Review 中允許任何情緒字眼的攻擊；當看到有人在 PR 中用不錯的寫法時，還會塑造鼓勵與讚美的文化，例如「這樣寫好讚，可讀性角度來說非常清楚」或者「這個測試案例寫得真好，我沒想過可能會出現這種極端案例」。

不要讓沒建設性的溝通文化得逞

當然，有些人在 Code Review 的留言，可能不會像上一段落提的例子那麼極端，使用會激起對立情緒的字眼。但有另一類人，在留言時會留一些沒建設性，或者對改進無具體幫助的內容。舉例來說「這跟我們程式碼風格指南寫的標準不一致」或是「這不符規範」，都是評論本身好像說了什麼，但又沒真的有具體指引。

如果用這種方式溝通，只會讓其他人要花時間去猜為什麼不符合、去推測符合標準應該怎麼改寫，這將導致帶來的成本大於留言本身的價值。

身為替團隊把關的人，要求團隊成員在寫留言時，要提具體有建設的論點，談「為什麼」這樣寫不好，以及更理想的寫法應該怎麼寫。舉例來說，假如不符合某個規範，就直接把哪一個規範寫出來，然後解釋為什麼這樣不符合。

或者可以反過來，以提問的方式，例如「今天用這種寫法，假如未來要拓展到另一個使用情境，會做大幅度的改動，你怎麼看這點呢?」讓對方直接看出問題在哪，然後接著引導討論更好的解決方式。

閱讀更多

除了上面提到的三個點外，資深工程師還有其他應該要在 Code Review 時把關的要點，我們在 E+ 的主題文中有更詳細的討論。感興趣的讀者，歡迎加入 E+ 後閱讀 (連結)。