譯者 | 劉汪洋

反饋就像一塊牛排 - 如果太生，沒有人喜歡；但如果過熟，難以下咽。

(ChatGPT)

通過不斷審查他人代碼，你不僅可以提升自己的技能，對你的職業發展也有很大好處。不僅可以幫助別人成長，也能為你所在的公司創造價值。

在本文中，我們要探討代碼審查的好處，以及一些在審查過程中應遵循的原則，如與同事的互動等。

名詞解釋

代碼審查：對作者代碼分支的書面反饋過程。

Pull Request：Github 上用于展示新分支與主分支之間差異的術語，你可以在其中發表評論。

代碼審查？是否已經過時？

如果你是一名敏捷開發者，你可能會懷疑代碼審查的必要性，可能會有這樣的觀點：

• 我們如果一直進行結對編程，就沒有必要再做正式的代碼審查了。因為這樣就不會有一個“陌生人”在你已經完成所有工作并花費了大量時間之后，才來評價你的代碼，而他對你的代碼的上下文可能一無所知。
• 代碼的正確性已通過 TDD （測試驅動開發）方法進行了驗證。
• 語法和風格可以由 linter 自動檢查。

這些考慮無疑是有道理的。

但：

代碼審查本質上是一種團隊成員之間和不同團隊之間的知識共享機制。

代碼審查的好處

一旦你不再把代碼審查視為負擔或者無聊的任務，你會發現，代碼審查能帶來很多好處。

為了支持這個觀點，我提出了一個用于在同事的 pull request 中提供反饋的框架。

W3H：即“為什么（why）、做什么(what)、何時(when)以及如何做(how)”

盡管我并非縮寫詞的狂熱愛好者，但我還是創建了一個 W3H 的縮寫詞，旨在概括我們在接觸新的代碼時所需要考慮的關鍵問題。

為什么(why)

代碼審查可能是由于你的組織內部的 CI/CD 流程強制推動的，因此，“為什么”的問題可以簡單地回答為“因為我被指示要這樣做”。

然而，有更有價值的問題值得我們思考：“為什么代碼審查如此重要？”或者說，“為什么我應該主動去進行代碼審查？”

首先，代碼審查對審查者和代碼作者來說都是一個提升自我技術水平的好機會。代碼作者可以得到有效的反饋和建議，有助于其技術水平的提升。審查者則可以從中學習新的編程技巧和習語。

此外，作為開發者，你還可以：

1. 更快地理解新的代碼庫。
2. 有更多的機會進行團隊內交流，尤其在團隊成員分布在不同地理位置的情況下。
3. 發現其他團隊工作中可能存在的重復問題。
4. 在代碼庫中推動最佳實踐的實行。
5. 提升你在其他工程師和管理者心中的專業形象和知識儲備。
6. 提高你的溝通技巧（我們將在“如何”一節中詳細討論）。
7. 結識新朋友！

做什么(what)

我們如何定義“優秀的”代碼？

在對別人的代碼發表任何評價之前，你需要明確好代碼的基本標準。

以下是一些通用的原則：

1. 代碼中不應存在 明顯的 錯誤，例如變量名的拼寫錯誤，或者不規范的代碼縮進。當我審查一個我并不太熟悉的模塊的 PR 時，我通常會從這些基礎的檢查開始。
2. 無論代碼完成的任務有多復雜，代碼本身都應該是 結構清晰 和 易于理解。
3. 代碼中不應存在嚴重的 性能問題，例如，一個可以通過一次循環讀取完成的列表被多次讀取。這在移動應用開發中尤其重要，因為這可能導致不必要的電池電量消耗。
4. PR 只應該修改完成任務（新特性，錯誤修復，重構）所必需的 文件。這不僅可以減輕審查者的工作壓力，而且如果出現了重大的生產問題，也會更容易找到問題并進行回滾。如果代碼涉及多個方面，建議作者將其拆分為兩個或更多的審查。
5. 清晰理解更改的目標。PR 的描述應該清晰地說明更改的內容或者鏈接到包含詳細信息的外部文檔（例如 Jira 或 Trello 工單）。理解了更改的目標后，再檢查更改是否滿足了預設的要求。
6. 如果 PR 是用來修復一個錯誤，修復方案還應該包含一組測試，這樣可以針對特定的場景進行測試，并避免相同的錯誤在未來再次發生。

何時(when)

你應該在什么時候進行代碼審查？

我通常每周安排兩次，每次約 30 分鐘的時間，審查其他團隊的 PR，這些與我自己團隊的工作并無直接關聯。如果我團隊有緊迫的項目截止日期，可能我會減少審查的時間；如果是工作相對清閑，并且有一些評論引發了大量的討論，我可能會投入更多的時間。

在我剛開始接觸 IOS 開發時，我花在代碼審查上的時間和學習 Swift 和 iOS 的時間幾乎一樣多。這使我能夠快速地熟悉新的代碼庫，語言習語，最佳實踐，以及了解項目中的關鍵人物。

我通常在面對學習新的大型代碼庫時，會立即開始進行代碼審查（這是作者有效學習和了解新代碼庫的一種方法）

如何(how)

編寫大量的評論可能會讓你感到枯燥乏味，因此你可能在表述上變得過于直白。書面交流與口頭交流有所不同，我建議你遵循以下建議：

友善待人

這一點無需多說。通常情況下，當我向我不太熟悉的人寫評論時，我會首先用一個簡單的 "你好 " 打招呼。如果你發現有什么項目缺失，不要直接用 "這是不完整的" 來表示，你可以詢問 "這里為什么會缺失？"

注意細節

嘗試在關鍵的和不那么關鍵的修改之間找到平衡，這需要你的經驗來指導。我們不希望因為一個小的空格問題而阻塞了一個重要功能的實現或者 bug 的解決！

詢問作者的意見

如果你提出的改動不顯著，或者你提出了重構的建議，那么最好在你的評論結尾處詢問一下 "你怎么看？" 或者 "你對此有什么看法？"

有時需要權衡

有些項目比其他項目更為重要。盡量不要因為小的修改而堅持不懈，以免造成發布延遲。你可以與作者達成共識，以后再創建一個"打磨"分支。然而，我常說：

以后 == 永不（later == never）

不要做假設

你正在審查一個 PR 并發現了一個明顯的錯誤，而這段代碼的開發者的職稱是"初級"。你可能會假設這個錯誤是由于他們的經驗不足，或對一些基本概念的理解不夠深入。也可能是他們匆忙完成的，或者在度過了一天的勞累后提交的。或者……可能有一些我們未能看到的、合理的原因在背后。如果有疑問，告訴作者： "可能是我漏掉了什么，但是……"

保持個人偏好的開放性

當你在代碼審查中建議更改時，確保這些更改是對代碼的實實在在的改進，而非審查者的個人偏好，這些偏好可能并不符合公司或行業的最佳實踐。當我提出這樣的更改時，我會說： "這是個人偏好的問題，但如果你愿意，可以試試<代碼更改>"

贊美作者

“看起來很好（LGTM）” 可能會被解讀為“我草率地審查了你的 PR”。對我來說，看到這個還好，但是，如果你真的認為代碼寫得很好，那就在 PR 中大膽地表揚。以下是值得贊揚的原因：引入了新的炫酷功能，或者進行了復雜但結構良好的重構。

如果 pull request 只包含一個簡單的顏色更改或函數參數的添加，那么過度的贊美可能會被誤認為是諷刺 。請選擇適當的語言表達。

副作用

盡管你持有善意，或者在代碼審查過程中為項目貢獻良多，有時你的行動可能仍會引發他人的反感。他們可能按照你的建議進行修改，但可能并未對你的審查表示感激。

有些人可能會駁斥你的建議

你的建議可能錯誤，無效，或者觸碰到了作者的自尊心，使他們認為修改代碼就等于否定自己。這沒有關系。然而，如果你認為某段代碼可能會導致嚴重的問題或性能影響，你應該考慮邀請其他開發者一起討論，例如在評論中@他們，引導他們參與討論。更好的做法是，嘗試直接通過電話或面對面的方式進行討論。

不要期待你的付出一定會得到回報

你或許為許多代碼審查和批準做出了貢獻，幫助審查了他人的代碼，但當你自己的代碼需要審查的時候，不要期待你的新 pull request 一定會受到關注。

你可能會收獲友情

去年，我為了更好地熟悉某個代碼庫，我對一個新接手的代碼庫進行了持續的代碼審查。我與許多開發者進行了積極的討論，最終，對倉庫中的一些模塊進行了改進。這是作者和我——這位新來的代碼審查者的共同努力的結果！我結識了一些愿意改進他們代碼、并始終對新建議和學習保持開放態度的優秀人才。季度結束時，我向他們請求正式反饋，收到了非常積極的回應。我們可以稱這種關系為"聯系"，甚至我愿意稱它為"友誼"。

結語

在這篇文章中，我們探討了持續進行代碼審查的諸多優點。 我推廣的 W3H 方法，就是一種給他人的代碼提供反饋的流程。

在我所工作的 Expedia Group™，我經常應用這種方法，公司也倡導并正式提出了"有意識的包容"這一價值觀。

本文要點總結如下：

1. 認識到審查他人代碼的好處（比如建立聯系，熟悉新的代碼庫，學習新的編碼風格等）。
2. 建立持續審查的習慣。
3. 提供超越你團隊范圍的反饋。
4. 避免過度假設。
5. 不要期待每個人都會同等地關注你的 pull request。
6. 保持友善。

你公司的代碼審查流程是怎樣的？你在工作中是否真正感受到代碼審提高了代碼質量？歡迎發表你的看法。

譯者介紹

劉汪洋，51CTO社區編輯，昵稱：明明如月，一個擁有 5 年開發經驗的某大廠高級 JAVA 工程師，擁有多個主流技術博客平臺博客專家稱號。

原文標題：The Importance of Being a Code Reviewer，作者：Carlo Sales