作為開發人員，我們都知道程式碼審查在理論上是一件好事。他們應該幫助我們：

• 儘早發現錯誤和安全問題
• 提高程式碼的可讀性
• 提供安全網以確保所有任務完全完成

現實情況是，程式碼審查對於每個參與者來說經常是一種令人不舒服的體驗，導致審查變得好鬥，無效甚至更糟，根本就不存在程式碼審查。

這是一個快速指南，可幫助您建立有效的程式碼審查過程。

為什麼要進行程式碼審查？

在稽核您的程式碼稽核流程時要回答的第一個問題是：我們的程式碼稽核的目的是什麼？當您提出這個問題時，您很快意識到執行程式碼審查的原因有很多。您甚至可能會發現團隊中的每個人都對他們稽核程式碼的原因有不同的看法。他們可能會認為他們正在審查:

1. 找到錯誤
2. 檢查潛在的效能或安全問題
3. 確保可讀程式碼
4. 驗證功能是否滿足要求
5. 確保設計合理
6. 分享已實施功能和更新設計的知識
7. 檢查程式碼是否符合標準......或其他數百個原因之一

如果團隊中的每個人都有不同的“為什麼”，他們會在程式碼中尋找不同的東西。這可能導致許多反模式：

• 程式碼審查需要很長時間，因為每個審閱者都會發現需要解決的一組不同問題
• 審稿人變得失去動力，因為每次稽核都會根據稽核人員的不同而引發不同型別的問題
• 審查可以在審查者與程式碼作者之間進行踢皮球，因為每次新迭代都會暴露出一組不同的問題

為您的程式碼稽核提供單一目的可確保參與稽核的每個人，無論他們是程式碼作者還是稽核者，都知道稽核的原因，並可以集中精力確保他們的建議符合這一原因。

我們在找什麼？

只有當我們理解為什麼要進行稽核時，我們才能找出我們想要在稽核期間尋找的內容。正如我們已經開始看到的那樣，在審查過程中我們可以尋找大量不同的東西，我們需要縮小我們真正關心的具體事項。

例如，如果我們確定我們的評論的主要目的是確保程式碼可讀和可理解，我們將花費更少的時間來擔心已經實現的設計，並花更多的時間關注我們是否理解方法以及功能是否在一個有意義的地方。這個特殊選擇的好處是，通過更易讀的程式碼，更容易發現錯誤或錯誤的邏輯。更簡單的程式碼通常也是更好的效能。

我們應該儘可能地自動化，因此人工程式碼審查員永遠不應該擔心以下情況：

• 格式化和樣式檢查
• 測試範圍
• 如果效能滿足特定要求
• 常見的安全問題

事實上，人工程式碼審查員應該關注的事情可能相當簡單 - 程式碼是否“可用”？

1. 可讀性
2. 可維護性
3. 擴充套件性

這些都是無法自動化檢查的。從長遠來看，這些是開發人員最重要的程式碼功能。

我們的業務關心：程式碼是否做了應該做的事情？是否有自動測試或一組測試來證明它？

最後，它是否符合所謂的非功能性要求？如果進行這些檢查，重要的是要考慮諸如監管要求（例如審計）或使用者需求（例如文件）之類的事情。

誰參與了程式碼審查？

有了明確的目的和一系列要在審查中尋找的東西，決定誰應該參與審查要簡單得多。我們需要決定：

1. 誰評審程式碼？

人們很容易認為應該是一個或多個資深或經驗豐富的開發人員。但是，如果重點是確保程式碼易於理解，那麼初級人員可能是正確的審查人員 。 如果沒有經驗的開發人員能夠理解程式碼中發生的事情，那麼每個人都可能很容易理解。

如果評審的重點是分享知識，那麼您可能希望每個人都檢視程式碼。對於其他用途的評審，您可能會有一組評論者，其中一些評審會隨機挑選。

2.誰簽署評審？

如果我們有多個評審者，重要的是要了解誰最終負責說評審已經完成。這可以是一個人，一組特定的人，一定數量的評審者，特定程式碼區域的特定專家，或者甚至可以通過一次否決來終止審查。在具有高度信任的團隊中，程式碼作者可能是決定何時足夠的反饋足夠並且程式碼已經更新以充分反映所引起的關注的人。

3. 誰解決了意見分歧？

評審可能有多個評審者。如果不同的評審人有相互矛盾的建議，作者如何解決這個問題呢？由作者決定嗎？或者是否有可以仲裁和決定最佳課程的領導或專家？瞭解在程式碼審查期間如何解決衝突非常重要。

什麼時候審查？

“何時”有兩個重要組成部分：

1. 我們什麼時候審查？

傳統的程式碼審查在所有程式碼完成並準備好投入生產時發生。在稽核完成之前，程式碼通常不會合併到主幹/主伺服器，例如拉取請求模型。這不是唯一的方法。如果程式碼審查用於知識共享，則可以在合併程式碼之後進行稽核（或者程式碼可以直接提交給主代）。如果程式碼審查是一個增量稽核，應該有助於改進程式碼的設計，那麼稽核將在實施過程中發生。一旦我們知道： 我們為什麼要做審查; 我們正在尋找什麼 ; 和誰參與，我們可以更容易的時候是進行審評的最佳時機決定。

2 審查何時完成？

不瞭解稽核何時完成是導致稽核無限期拖延的主要因素。沒有什麼比永遠不會結束的查更令人失去興趣，開發人員覺得他們一直在做同樣的事情而且還沒有投入生產。決定稽核何時完成的指導原則取決於誰參與稽核，以及稽核何時進行：

• 通過 知識共享評論，一旦每個人都有機會檢視程式碼，就可以簽名
• 通過閘道器評論，通常一名指定的高階管理人員（守門人）表示，當所有要點得到解決時，它都是完整的

其他型別的評論可能有一組標準需要在評審完成之前通過。例如：

• 所有註釋都通過程式碼中的修復程式解決
• 所有評論都導致程式碼更改，或導致問題跟蹤器中的故障單（例如，建立新功能或設計更改的故障單;為即將釋出的功能故障單新增其他資訊;或建立技術債務故障單）
• 標記為showstoppers的評論都以某種方式得到了解決，未來需要學習的觀察或教訓的評論不需要“修復” 

我們在哪裡審查？

程式碼審查不必在程式碼審查工具中進行。結對程式設計是程式碼審查的一種形式。稽核可能只是將同事拉到一邊並隨身攜帶程式碼。可以通過簽出分支並在文件，電子郵件或聊天頻道中發表評論來完成評論。或者程式碼審查可能通過github pull請求或一段程式碼審查軟體發生。

總結

在進行程式碼審查時需要考慮很多事情，如果我們為每次程式碼審查都擔心所有這些問題，那麼任何程式碼都幾乎不可能通過稽核流程。實施適合我們的程式碼審查流程的最佳方法是考慮：

• 我們為什麼要做審查？評審人的工作更加容易，目的明確，程式碼作者在稽核過程中會有更少的令人討厭的意外
• 什麼是我們尋找什麼？當我們有目的時，我們可以建立一個更集中的事物來檢查程式碼
• 誰參與了？誰負責稽核，誰負責解決意見衝突，誰最終決定程式碼是否合適？
• 稽核什麼時候完畢？在處理程式碼時或在流程結束時，可能會反覆進行稽核。如果我們沒有關於程式碼何時最終可行的明確指導，那麼審查可能會永遠持續下去。
• 我們在哪裡稽核？程式碼審查不需要特定的工具，審查可以像通過我們走進同事辦公桌一樣簡單。

一旦這些問題得到解答，我們就應該能夠建立一個適合團隊的程式碼審查流程。請記住，稽核的目標應該是將程式碼投入生產，而不是證明我們有多聰明。