一位開發者提交了一個拉取請求，為結帳服務添加了折扣計算功能。測試通過，差異很小。一位審核員兩分鐘就批准了，並評論“LGTM”（看起來不錯）。三個月後，一位團隊成員需要修改同一個功能，卻發現它把定價規則、舍入和資料庫存取混雜在了一起。沒有人能確定哪些操作是允許的。
這是一個範例場景，並非已記錄的事件。它展示了當同儕代碼審查作為一種學習活動發揮作用時，應該產生什麼結果：審查者能夠看到合理的變更，發現尚未被認定為缺陷的問題，並以作者能夠理解的方式進行解釋。
本指南面向工程賦能負責人和工程經理，展示如何進行設計。 程式碼審查練習 與其指望評審員在待審稿件中自然而然地發現這項技能，不如有意識地培養牠。它涵蓋了效能問題、需要診斷的差距、如何安排準備和練習、一個已完成的範例，以及如何檢驗這項技能能否應用於實際評審。在使用前，請務必讓資深工程師驗證每個案例、缺陷和標準。
什麼是程式碼審查練習？
程式碼審查練習是一種結構化的實踐任務，開發人員需要審查預先準備好的變更，解釋他們發現的問題及其重要性，並獲得關於解釋品質的回饋。這與團隊日常進行的審查有所不同。變更事先選定，其中的問題也已明確，其目的在於提升審查者的能力，而非發布變更本身。
要聞速覽
| 問題 | 簡答 |
|---|---|
| 任務是什麼？ | 解釋評審結果，並向作者提供可採納的回饋意見。 |
| 你得了多少分？ | 研究結果的準確性以及解釋的實用性。 |
| 統計缺陷數量就足夠了嗎？ | 不。評論不僅僅是關於缺陷，所以只獎勵缺陷數量的做法會養成錯誤的習慣。 |
| 認知需求是什麼？ | 分析和評估設計方案，然後提出更好的建議。 |
| 誰來驗證這個案例？ | 負責程式碼庫的工程經理或資深工程師。 |
| 哪些問題是運動無法解決的？ | 審查時間長、所有權不明、快速合併的壓力。 |
| 你怎麼知道它奏效了？ | 一項新的、未曾公開的變更，根據既定標準進行審查，並根據實際審查結果進行後續跟進。 |
1. 描述效能問題
首先，用一句話概括任務：審閱者需要解釋他們發現的問題、問題的重要性以及作者可以採取的應對措施。 「解釋」是關鍵。發現問題是成功的一半，而另一半則是能夠清楚地表達出來，讓持有不同觀點的同事也能理解、權衡並採取行動。
現代程式碼審查的研究表明，不應僅關注缺陷查找。在微軟的一項研究中，Bacchelli 和 Bird 對開發人員和管理人員進行了觀察、訪談和調查。他們發現，發現缺陷仍然是程式碼審查的主要動機，但審查的重點遠不如人們預期的那樣在於缺陷。程式碼審查還帶來了其他益處，例如知識共享、團隊意識和替代解決方案。研究人員將對程式碼和變更的理解描述為程式碼審查的關鍵方面。Bacchelli 和 Bird，ICSE 2013這是一項針對一家公司團隊的研究，所以請將其作為理解性設計的理由，而不是作為您自己團隊的衡量標準。
谷歌發布的審查標準也指向同一個方向。它告訴審查員，即使程式碼並不完美，只要更改能夠顯著改善程式碼的整體健康狀況，就應該優先批准；它還指出，審查可以教導開發者一些新東西，因此歡迎有助於他人學習的評論。谷歌工程實踐這兩個來源都將評審描述為運用和傳遞判斷力的場所。這正是你的練習應該著重演練的內容。
2. 診斷學習與情境差距
將這項任務與你目前課程的練習和評量內容進行比較。
- 目前的做法是否使用了實際任務？ 如果新審閱者透過閱讀風格指南並審查實際的拉取請求來學習，他們就能在真實的工作環境中練習，而沒有犯錯的餘地。如果評估方式是檢視禮儀的測驗，那麼它衡量的是審查者對規則的記憶，而不是將規則應用於實際變更的能力。
- 認知需求是什麼？ 在修訂後的布魯姆分類法中，判斷設計是否合理並權衡其利弊屬於分析和評估層面，而提出更優的結構則屬於創造層面。如果你的練習只問“這段程式碼是做什麼的？”，那就止步於理解。我們的指南… 將學習活動與布魯姆分類法相匹配 展示如何將活動與水平相匹配。
- 除了技能之外，還有其他因素阻礙了你嗎？ 檢查審核時間、工具、負責人和團隊規範。如果審核人員每個拉取請求只有五分鐘時間，那麼任何努力都無法產生深思熟慮的解釋。如果作者將每則評論都視為批評，審核人員就會逐漸淡化他們的意見，直到最終什麼都不說。將這些問題報告給能夠解決它們的人員。
3. 設計準備、練習與回饋
給每個階段分配單獨的任務。
準備。 在審閱者開始審查之前，請先確認他們需要哪些資訊：團隊的審查清單、所依據的設計原則，以及如何在你們的工具中解讀差異。審閱過程應保持自主節奏，盡量簡短。回顧性檢查僅用於確認前提條件，並不能證明審閱者俱備審閱能力。
實踐。 使用預先準備好的變更，其中包含少量不同類型的預設問題：一個正確性錯誤、一個可維護性問題（例如開篇範例中的職責混合）、一個不清晰的名稱或缺少的測試，以及一些沒有問題的程式碼。請審閱者寫下他們會留下的評論，對這些問題進行排序，並說明他們還需要哪些資訊。 CodeRefinery 的實作課程展示了這個模式：人們會建立一個包含一個小拼字錯誤和一個較大錯誤的拉取請求，然後以同儕身分進行審查（CodeRefinery，實踐程式碼審查）從你自己的程式碼庫構建，這樣約定和權衡取捨才是真實的。
反饋。 將其與審閱者所做的決定連結起來。 「你注意到了舍入問題，但你的評論只是說『這看起來不對勁’，卻沒有說明是哪個輸入導致了這個問題」比「發現了 4 個問題中的 2 個」更有用。
即時輸入還是非同步審核？ 當問題含糊不清時，即時回饋最有價值，審查者可以從資深工程師的解釋中獲益，了解他們提出問題或放棄問題的原因。非同步審閱足以將評論與帶有註釋的專家審閱進行比較。
4. 透過一個實際例子進行分析
舉例說明。工程經理在使用前應驗證案例和答案標準。
案子。 一項變更在結帳服務中新增了折扣計算功能。該變更通過了所有測試。在一個函數中，它應用百分比折扣和固定折扣，對結果進行四捨五入，寫入資料庫並發送事件。它只有一個測試案例，用於測試單一百分比折扣。
任務。 審查者寫下他們要留下的評論，對他們的擔憂進行排序，並說明在批准之前他們需要知道哪些資訊。
第一次嘗試。 「看起來沒問題，測試通過了。或許可以拆分？」審閱者註意到了一些問題，但沒有說明是什麼問題，為什麼重要，或應該怎麼做。作者無法據此採取行動。
反饋並重試。 主持人會問：未來對這個功能的改變可能會破壞哪些現有功能？在批准之前，您會要求作者添加哪些內容？重試環節要求針對每個問題給予具體評論，包括原因和建議。
一次更有力的嘗試。 該函數應用兩種折扣、四捨五入、保存並發布事件，因此四捨五入方式的更改可能會同時影響我們儲存和發布的內容。我建議將定價規則移到一個純函數中，以便我們可以單獨進行測試。目前的測試僅涵蓋百分比折扣。我希望增加固定折扣和使總金額為零的訂單測試。我不確定事件是否應該在總金額為零時觸發，因此我建議向作者諮詢。請注意，此評論指出了問題所在，給出了原因，提出了具體的建議，並說明了審閱者不了解的內容。
5. 評估能力並制定轉移計劃
能力證明是指對評審員未曾見過的新變化進行評估的表現。對評估結果的準確性和解釋的實用性進行評分。一個簡單的評分標準是每個標準採用 0 到 2 分的等級：
| 標準 | 可觀察的證據 |
|---|---|
| 任務執行 | 找出變更中的相關問題，並記錄每項問題的證據。 |
| 推理 | 解釋每個問題的重要性，提供替代方案，並說明仍然存在的不確定因素。 |
| 邊界 | 遵循團隊的審查規則，並在缺乏權限或背景資訊時尋求協助或資訊。 |
評分標準：0 分錶示缺失或缺乏支持，1 分錶示部分缺失但有相關遺漏，2 分錶示完整且符合既定標準。請單獨定義關鍵錯誤，例如核准有資料遺失風險的變更，以免高分掩蓋關鍵錯誤。請與工程經理共同調整評分標準；本評分細則僅為初步方案，並非最終驗證的就緒標準。有關評分依據的更多信息，請參閱我們的指南。 設計具有實用回饋的互動練習.
制定遷移計劃。演練結束後，幾週後使用相同的標準，抽取部分審查者的實際審查記錄進行檢查。與訓練前的基線數據進行比較，並預先確定樣本人群和時間安排。在評估演練效果之前，也要考慮同期發生的其他變化，例如新的審查工具或人員變動。
6. 使用 AhaSlides 進行即時或自主節奏的練習
您可以將練習安排在研討會上，也可以讓審閱者自行完成。在現場會議中，展示準備好的修改內容，並使用互動式投影片進行討論：
- 選擇答案 對於「您會先提出哪個問題？」這個問題，請將預設的問題當作選項。在公佈您自己的排名之前，先展示所有選項的分佈。
- 開放式 對於「寫下你想留下的評論」這一題，審閱者可以將自己的措辭與其他審閱者的措辭進行比較，這正體現了審閱者的解釋能力。
- 評定量表 為了“這有多嚴重？”，以便小組能夠看到判斷上的差異，並討論原因。
對於無法到場的審閱者，可以依照相同的流程進行自主學習，每次回覆後都會顯示專家註解。在您使用自己的程式碼進行測試之前，請將任何關於程式碼執行、整合或人工智慧功能的說法視為未經證實。
如果您也對程式碼審查員進行人工智慧編寫程式碼的培訓，請參閱我們的配套指南。 AI產生的程式碼審查培訓那篇文章是關於審核產生的輸出結果的。這篇文章是關於人們如何互相審查彼此的工作，以及如何解釋他們發現的問題。
可能存在的限制
- 複習時間。 一則深思熟慮的評論需要比「LGTM」更長的時間，而截止日期卻迫使人們選擇簡短的版本。
- 團隊規範。 如果回饋被解讀為個人批評，審查者會淡化或放棄他們的評價。
- 案件承保範圍。 一項練習展現了幾種類型的擔憂。分數並不能反映評論者的整體判斷。
- 轉讓。 車間裡的表現與繁忙排隊時的表現並不相同，所以也要查看真實評價。
儘早將這些問題告知贊助商，並制定單獨的解決方案。練習可以提高審閱者觀察和解釋的能力，但並不能創造時間或規範。
常見問題
什麼是程式碼審查練習？
這些練習任務是預先準備好的，開發人員需要審查一個已知存在問題的變更，寫下他們會留下的評論，並獲得關於準確性和實用性的回饋。其目的是為了提升審查者的技能，而不是為了發布變更。
如何評估審稿者的判斷力是否有提升？
提出他們未曾見過的新變化，並根據既定標準對發現的問題和解釋進行評分。幾週後，再檢查一些真實的評論樣本。關於評論規則的測試僅用於確認前提條件。
同儕程式碼審查的主要目的是發現錯誤嗎？
發現缺陷仍然是主要動機之一，但微軟的一項研究發現，評審中缺陷的佔比低於預期，同時也促進了知識共享和團隊意識的提升。設計評審活動時，應獎勵解釋和理解，而不僅僅是缺陷數量。
從哪兒開始
選擇團隊經常需要評估的變更類型。撰寫績效說明，請一位資深工程師準備一個包含三到四個預設問題的變更範例，並擬定一個包含三個評分標準的評估表，評分範圍為 0 到 2 分，並列出關鍵錯誤。先在一個小組中進行試點，然後將他們下次正式評估的結果與基準值進行比較。
若要了解如何讓回顧練習在您的團隊中即時進行，並在之後以自定進度重複使用，請探索 AhaSlides。
