程式碼審查是建立優秀軟體中最被低估的部分之一。
這一開始可能看起來困難和混亂，但實際上比你想像中的簡單得多。
這篇文章簡要概述了11種實用的方法和策略，以協助開發者進行程式碼審查。
這將幫助你提高程式碼審查的能力。
🎯 什麼是程式碼審查？
在深入探討之前，讓我們花點時間來了解什麼是程式碼審查。
程式碼審查是開發者互相檢查代碼，以提高其質量，然後再合併或發佈的過程。
「程式碼審查」這個術語可以指很多事情，從簡單地閱讀你朋友的代碼，到20人的會議中詳細分析每一行。
主要涉及兩個角色：
審查者：閱讀程式碼並決定何時可以合併到團隊的代碼庫中。作者：編寫程式碼並提交審查，主要通過拉取請求進行。
當審查者「批准」變更時，審查結束。你會看到 LGTM，這是「看起來不錯」的縮寫，意思一樣。
如果你有興趣了解更多，可以參考 GitLab 的 什麼是程式碼審查？ 指南。它列出了優點、缺點、一些方法和最佳實踐。
讓我們來看看在進行程式碼審查時你應該考慮的提示和策略。
1. 使用 AI 工具獲取上下文反饋。
使用 AI 工具可以幫助你節省時間，並確保合併的程式碼質量確實很好。
我搜尋了很多工具（主要是在 Reddit 上），發現最好的一個是 CodeRabbit。
根據官方網站的說法，已經使用 CodeRabbit 審查了500萬個拉取請求，這說明了它的可信度。而這在處理私有代碼庫時非常重要。
它使用機器學習算法來分析你的代碼庫，識別潛在問題，並提供上下文感知的拉取請求反饋。
✅ 你獲得逐行反饋和簡單的一鍵修正。
✅ 你可以通過實時聊天創建問題來討論審查意見。
✅ 它可以與 GitHub、GitLab、Azure DevOps、BitBucket Cloud（測試版）集成。
你只需使用命令來執行某些操作，例如 @coderabbitai summary、@coderabbitai review。該 AI 隨著時間的推移進行學習，並確定特定於倉庫的某些最佳實踐。
你可以觀看這個快速演示！
https://www.youtube.com/watch?v=3SyUOSebG7E
在免費版本中，你可以獲得拉取請求的摘要（這是最重要的），他們提供免費試用，以幫助你理解這是否適合你。
你可以在 文件 中找到更多資訊，而 CodeRabbit 是開源的，可以進行查看。
你還可以閱讀Linux 基金會如何使用 AI 程式碼審查減少開源軟體中的手動瓶頸。
如果你想探索其他工具，這裡有一些選擇：
Codacy- 自動識別和修復代碼質量問題。Synk- 用於查找和修復你的代碼/依賴項中的漏洞。Bito- 協助代碼審查的助手，幫助你識別問題。Qodo- 提高審查質量，同時減少來回延遲。Code Review GPT GitHub Actions- 使用 GPT 自動化程式碼審查，直接在 GitHub Actions 中。GitHub Copilot- 最受信任的 AI 助手編程員。PullRequest- 結合 AI 與專家人力審查。
我知道這些描述聽起來幾乎一樣，建議你探索其他博客以找到更多工具。
2. 將你的審查聯繫到原則，而不僅僅是意見。
我是一個開源項目的維護者，所以我知道給予反饋有多麼困難。
如果一位程式設計師向你發送他們認為很棒的變更列表，而你給他們列一大堆為什麼這不行的理由，那就會傳遞一個完全錯誤的訊息。
大多數情況下，作者將對他們代碼的批評視為他們是一個無能程式設計師的間接方式，但這絕對不是事實。
<mark>在對代碼給予反饋時，解釋你建議的變更和變更的理由。</mark>
語氣小改變可以帶來很大的不同：
❌ <q>我們應該合併這兩個函數。</q>
✅ “這個函數同時處理身份驗證和日誌記錄，這違反了單一職責原則。讓我們將它們分開。”
這樣寫會將你基於意見的反饋轉化為建設性的方式。要客觀，並在可能的情況下給出具體的證據，提供鏈接。
3. 使用常見技術來進行不同類型的審查。
有許多開發者不知道的技術，例如：
⚡ 展示與說明審查：作者向審查者展示他們的變更，解釋這些決策背後的原因。
⚡ 基於清單的審查：使用預定義的清單以保持一致性，避免忽視關鍵領域。
⚡ 橡皮鴨審查：作者向審查者解釋他們的代碼，就像在解釋給一隻「橡皮鴨」一樣。
⚡ 清單自動化審查：結合自動化工具和人工審查來發現常見問題，如風格違規。
⚡ 同一艘船的兩個豌豆：你在對話中對一行代碼進行評論，而另一位貢獻者對同一拉取請求中的另一行代碼給出反饋。
⚡ 變色龍審查：根據同儕的貢獻類型來調整你的 PR 審查。
⚡ 教學審查：審查者指出問題，但還解釋為什麼這些變化是必要的。
⚡ 逐個提交審查：每個提交都單獨審查，使其更易於跟踪變更和理解思考過程。
還有更多技術，如 模式識別、變更影響分析、追蹤基於代碼的閱讀等，這些你可以自行探索。
如果你有興趣閱讀更多，可以查看以下幾篇有趣的博客：
- 如何給予有效程式碼審查的好反饋 由 freeCodeCamp 發表。
- 10 種最佳程式碼審查技術 由 awesome code reviews 發表。
一旦你知道這些技術，只需結合你的個人經驗應用它們，這將為你提供更好的方向感。
4. 請求變更，而不是命令變更。
正常的程式碼審查對話轉變為個人意見的風險很高。
想像一下對你的團隊成員說：「幫我拿那份報告，順便也給我拿杯咖啡」，這聽起來非常苛求，並不是其他人所期待的。
| 以命令形式框架的反饋 | 以請求形式框架的反饋 |
|---|---|
審查者：「重構 User 類為幾個小類別。」 |
審查者：「我們能否將 User 類重構為幾個小類別？」 |
| 作者：「我覺得這沒有必要，這個類別可以正常運行。」 | 作者：「我們可以這樣做，但我認為拆開可能會使事情更複雜。你怎麼看？」 |
如果命令感覺更直接，可能會導致防衛性的回應。
<mark>人們欣賞對其工作擁有控制感。當你發出請求時，這會給他們一種擁有感。</mark>
對你的反饋加倍小心並不需要 10 倍的努力，但會使事情順利得多。
5. 使用程式碼審查清單讓工作變得容易得多。
系統化的程式碼審查方法將導致更快且更準確的過程。
這就是所謂的 審查清單 的概念。它是一組審查者在每次審查代碼時遵循的準則或項目。
<mark>你不必從零開始制作一個，直接下載一個現成的清單並根據需要調整即可。</mark>
你可以讓它更集中於你的技術棧，專注於一些特定領域，如可訪問性或安全性。
這能夠建立團隊成員之間對哪些是重要的事物的共識，並減少衝突、分歧或在程式碼審查過程中的不必要的反覆。
例如，如果你在開發一個 React 應用程序，你可能想包括對鉤子使用、組件可重用性或高效狀態管理的檢查。
團隊中的每個人都會對在審查代碼時要尋找什麼有一致的認識。隨著時間的推移，這將加速審查過程，而不會影響質量。
有一個由 Michaela 提供的 免費 Gumroad 產品，你可以在那裡找到一個不錯的清單。
你也可以查看 GitHub 上的程式碼審查清單，那裡擁有超過900顆明星。
6. 避免在任務上浪費時間，這些任務可以輕易通過格式工具處理。
我們的注意力範圍正在逐漸減小，信息過載的情況下尤其如此。
在會議、電子郵件和各種其他干擾中，找到時間專注於代碼真的很難。閱讀別人的代碼會消耗你的心理耐力。
我的建議是<mark>不要在那些可以輕鬆由電腦完成的繁瑣工作上浪費時間和精力。</mark>
例如，與其手動向作者解釋縮排問題，一個合適的格式工具可以在幾秒鐘內處理。
| 人工審查者所需的努力 | 格式化工具所需的努力 |
|---|---|
| 審查者尋找空格問題並發現錯誤。 | 沒事！ |
| 審查者寫下備註解釋問題。 | |
| 審查者徹底檢查備註以確保清晰。 | |
| 作者閱讀備註並修正縮排。 | |
| 審查者驗證修正。 |
你也可以將這應用到程式碼審查中的其他重複性任務中。以下是一些例子：
| 任務 | 自動解決方案 |
|---|---|
| 確認代碼是否遵循風格指南 | 像 ESLint（用於 JavaScript）或 Pylint（用於 Python）的代碼檢查器 |
| 檢查文檔中的死鏈接 | 鏈接檢查工具，如 Markdownlint 或 HTML 檢查工具 |
| 驗證代碼是否遵循安全最佳實踐 | 安全檢查工具，如 SonarQube 或 Brakeman（用於 Ruby on Rails） |
| 檢查註釋中的拼寫和語法 | 拼寫檢查工具，如 Code Spell Checker 或 write-good 用於 markdown 文件 |
| 確保沒有秘密（API 密鑰、密碼..）被硬編碼 | 秘密掃描工具，如 Git-secrets 或 TruffleHog |
| 檢查項目是否有適當的測試覆蓋率 | 代碼覆蓋工具，如 Istanbul（JavaScript）或 Jacoco（Java） |
| 驗證依賴項是否是最新的 | 依賴管理工具，如 Dependabot 或 Greenkeeper |
與其浪費時間修正基本的錯誤，倒不如專注於更複雜的問題。
而且，沒有人喜歡聽到來自人類的錯誤，當這信息來自計算機時，這對於自尊心來說要輕鬆得多！
提示：與團隊合作，在你的程式碼審查工作流程中設置自動檢查，例如使用 Git 中的 pre-commit hooks 或 GitHub 的 webhooks。
7. 在剩餘的修正非常簡單的情況下批准。
許多審查者認為應該在每一個小問題解決後才批准程式碼。這可能會導致作者和審查者之間不必要的「來回」延遲。
如果只剩小問題，比如拼寫錯誤或變量名稱，則需明確表示這些是可選的，讓作者知道這並不是批准的條件。
不要因為變量名稱不完美而拖延程式碼。
<mark>在偶爾的2%的情況下多花點時間，總比為其他98%造成不必要的延遲要好？想一想。</mark>
8. 尋找拆分大型審查的機會。
我見過拉取請求包含30多個文件改動和1000多行代碼的情況。
一次性審查如此巨大的變更非常困難。大多數情況下，我們作為審查者會錯過一些關鍵內容。
一個理智的解決方案是拆分大型審查。不要只要求作者自己完成，幫助找出合邏輯的斷裂點。如果變更獨立影響文件，則按文件分組。
對於更複雜的情況，你可以找到簡單的邏輯，將其移動到單獨的變更列表。
如果代碼質量很差，則必須明確說明需要進行拆分。
<mark>審查幾個混亂的300行變更列表總比審查一個大規模的600行代碼轉存要好。</mark>
9. 限制自己只給高層次的反饋。
我通常避免一次給太多反饋，以免讓作者感到不知所措。
首先針對大問題給出高層次的反饋，例如架構問題或重大錯誤。這些對影響最大。
當這些得到修正後，再針對命名或小變更等不太重要的細節提出意見。
<mark>這樣一來，作者可以集中精力首先修復最大問題，而不會被那些可能並不緊急的小事所困擾。</mark>
10. 不要忘記對話另一端是真正的人。
在緊迫的截止日期混亂中，很容易忘記對話另一端是真正的人。
🎯 對抗偏見。
每個人都有潛意識的偏見，最近Google的一項研究顯示，認同女性的開發者在程式碼審查過程中面對的壓力比認同男性的同行要多，這是相當震驚的！
有意識到這些偏見並採取必要的行動（即進行審查的審查）以減少程式碼審查中的偏見或任何與成見有關的事物是非常重要的。
🎯 避免僵局。
程式碼審查的最糟糕結果是僵局，你拒絕批准變更列表，作者也拒絕做出改變。
討論的語氣會非常緊張，因此必須進行溝通。誠實且簡單的交流將打破這種局面。
🎯 簡單的語氣。
<mark>避免在程式碼審查中使用「你」字。</mark>
你注意到這些的區別了嗎？
❌ 能否你將這個變量重命名為更具描述性的名稱？
✅ 能否我們將這個變量重命名為更具描述性的名稱？
這小小的語調改變可以帶來不同的效果。
11. 慶祝優秀的程式碼。
程式碼審查不一定總是要指出錯誤。這也是突出好東西的絕佳機會！
說像「我喜歡你如何將其分解，這樣更容易跟隨」這樣的話真的很有幫助。小小的讚美可以帶來很大影響（即使你沒有意識到）。
這顯示了你不僅僅是要指出錯誤，而是實際上注意到他們做得對的事情。
<mark>這不是為了讓人感覺良好，而是創造一種正面的氛圍，促使他們做得更好。</mark>
我運用了自己作為開源維護者的經驗，所以希望你能找到一些有用的東西。
如果你有任何反饋或其他在進行程式碼審查時需要注意的事情，請告訴我。
祝你有個美好的一天！下次再見 :)
| 你可以查看<br />我在 anmolbaranwal.com 的工作。<br />謝謝你的閱讀！🥰 | <a href="https://twitter.com/Anmol_Codes"><img src="https://img.shields.io/badge/Twitter-d5d5d5?style=for-the-badge&logoColor=000" alt="Twitter 帳號 Anmol_Codes 的個人資料" ></a> <a href="https://github.com/Anmol-Baranwal"><img src="https://img.shields.io/badge/github-181717?style=for-the-badge&logoColor=white" alt="GitHub 帳號 Anmol-Baranwal 的個人資料" ></a> <a href="https://www.linkedin.com/in/Anmol-Baranwal/"><img src="https://img.shields.io/badge/LinkedIn-0A66C2?style=for-the-badge&logoColor=white" alt="LinkedIn 帳號 Anmol-Baranwal 的個人資料" /></a> |
|---|
原文出處：https://dev.to/anmolbaranwal/11-practical-tips-to-make-code-reviews-easier-as-a-developer-16kc
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式