為您的團隊帶來健康的代碼審查心態

“代碼審查”是開發過程中的一個時刻，您（作為開發人員）和您的同事一起工作，並在最近的一段代碼發布之前尋找錯誤。 在這樣的時刻，您可以是代碼作者或審閱者之一。

在進行代碼審查時，您可能不確定要查找的內容。 另一方面，在提交代碼審查時，您可能不知道要等待什麼。 雙方缺乏同理心和錯誤的期望可能會引發不幸的情況，並匆忙推進這一進程，直到雙方都經歷不愉快。

在本文中，我將分享如何通過在代碼審查期間改變思維方式來改變這一結果：

• 作為一個團隊
• 作為作者
• 作為審稿人

團隊合作

培養合作文化

在我們開始之前，了解為什麼需要審查代碼的價值至關重要。 知識共享和團隊凝聚力對每個人都有好處，但是，如果以糟糕的心態完成代碼審查，代碼審查可能會耗費大量時間並產生不愉快的結果。

團隊的態度和行為應該包含非判斷性協作的價值，以學習和分享為共同目標——無論其他人的經驗如何。

在您的估計中包括代碼審查

完整的代碼審查需要時間。 如果更改需要一周時間，不要期望代碼審查不到一天。 它只是不能那樣工作。 不要急於進行代碼審查，也不要將其視為瓶頸。

代碼審查與編寫實際代碼一樣重要。 作為一個團隊，請記住在您的工作流程中包含代碼審查，並設定對代碼審查可能需要多長時間的預期，這樣每個人都會同步並對他們的工作充滿信心。

通過指南和自動化節省時間

保證一致貢獻的一種有效方法是在項目中集成一個 Pull Request 模板。 這將有助於作者提交一份完整描述的健康 PR。 PR 描述應該解釋改變的目的是什麼，背後的原因，以及如何重現它。 屏幕截圖和參考鏈接（Git 問題、設計文件等）是不言自明的提交的最後潤色。

這樣做可以防止審閱者提前發表評論，詢問更多細節。 另一種讓代碼審查看起來不那麼挑剔的方法是在審查者參與之前使用 linter 來發現代碼格式和代碼質量問題。 每當您在審核過程中看到重複的評論時，請尋找將其最小化的方法（使用更好的指南或代碼自動化）。

留個學生

任何人都可以進行代碼審查，並且每個人都必須接受代碼審查——無論資歷級別如何。 感激地接受任何反饋，以此作為學習和分享知識的機會。 將任何反饋視為公開討論，而不是防禦性反應。 正如瑞安假日所說：

“業餘愛好者是防守型的。 專業人士發現學習（甚至偶爾出現）是令人愉快的； 他們喜歡接受挑戰和謙卑，並把教育作為一個持續不斷的過程。 （……）”

——瑞恩·霍利迪，自我是敵人

保持謙虛，因為一旦你不再是學生，你的知識就會變得脆弱。

選擇審稿人的藝術

在我看來，挑選審閱者是團隊進行有效和健康的代碼審查最重要的決定之一。

假設您的同事正在提交代碼審查並決定標記“每個人”，因為不知不覺中，她/他可能希望加快流程，提供可能的最佳代碼或確保每個人都知道代碼更改。 每個審閱者都會收到通知，然後打開 PR 鏈接，看到很多人被標記為審閱者。 “別人會做”的想法突然出現在他們的腦海中，導致忽略代碼審查並關閉鏈接。

由於還沒有人開始審稿，你的同事會提醒每一位審稿人去做，即給他們施加壓力。 一旦審稿人開始這樣做，審稿過程就會永遠持續下去，因為每個人都有自己的意見，而達成共識是一場噩夢。 同時，無論誰決定不審查代碼，都會收到大量包含所有審查評論的電子郵件通知，從而影響他們的工作效率。

這是我看到的比我想的更多的事情：拉取請求，一群人被標記為審閱者，具有諷刺意味的是，在非生產性代碼審查中結束。

在選擇審閱者時，有一些常見的有效流程： 一個可能的流程是挑選兩到三個熟悉代碼的同事，請他們擔任審閱者。 Gitlab 團隊解釋的另一種方法是採用鍊式審閱流程，其中作者選擇一個審閱者，然後再選擇另一個審閱者，直到至少有兩個審閱者同意代碼。 無論您選擇哪種流程，都要避免過多的審閱者。 能夠信任同事對代碼的判斷是進行有效和健康的代碼審查的關鍵。

有同理心

發現要改進的代碼片段只是成功的代碼審查的一部分。 同樣重要的是通過對同事表現出同理心來以健康的方式傳達反饋。

在撰寫評論之前，請記住設身處地為他人著想。 寫的時候很容易被誤解，所以在發送之前檢查你自己的話。 即使談話開始變得醜陋，也不要讓它影響到你——始終保持尊重。 對別人說好話從來都不是一個糟糕的決定。

知道如何妥協

當討論沒有迅速解決時，將其帶到個人電話或聊天中。 一起分析它是否是一個值得讓當前變更請求癱瘓的主題，或者它是否可以在另一個主題中解決。

靈活但務實，知道如何平衡效率（交付）和有效性（質量）。 作為一個團隊做出妥協是一種妥協。 在這些時刻，我喜歡將代碼審查視為一次迭代，而不是最終解決方案。 下一輪總是有改進的餘地。

面對面的代碼審查

以結對編程風格將作者和審閱者聚集在一起可能非常有效。 就個人而言，當代碼審查涉及復雜的更改或有大量知識共享的機會時，我更喜歡這種方法。 儘管這是一次離線代碼審查，但對所進行的討論留下在線評論是一個好習慣，尤其是在會議結束後需要進行更改時。 這對於讓其他在線評論者保持最新也很有用。

從代碼審查結果中學習

當代碼審查經歷了很多更改、花費了太長時間或已經進行了太多討論時，請將您的團隊聚集在一起並分析原因以及可以從中採取哪些措施。 當代碼審查很複雜時，將未來的任務拆分成更小的任務會使每次代碼審查變得更容易。

當經驗差距很大時，採用結對編程是一種具有令人難以置信的結果的策略——不僅用於知識共享，還用於離線協作和交流。 無論結果如何，始終以具有明確期望的健康充滿活力的團隊為目標。

作為作者

作為作者進行代碼審查時，主要關注的一個問題是在第一次閱讀代碼時盡量減少審查者的驚訝。 這是進行可預測且流暢的代碼審查的第一步。 這是你如何做到的。

建立早期溝通

在編碼過多之前與您未來的審閱者交談絕不是一個壞主意。 無論是內部還是外部貢獻，您都可以在開發開始時一起進行改進或一些結對編程來討論解決方案。

作為第一步尋求幫助並沒有錯。 事實上，在審查之外合作是防止早期錯誤和保證初步協議的第一個重要步驟。 同時，您的審閱者會知道將來要進行的代碼審查。

遵循指南

在提交要審核的拉取請求時，請記住添加描述並遵循指南。 這將節省審閱者花時間了解新代碼的上下文。 即使您的審稿人已經知道它是關於什麼的，您也可以藉此機會提高您的寫作和溝通技巧。

成為您的第一位審稿人

在不同的上下文中查看您自己的代碼可以讓您找到您在代碼編輯器中遺漏的內容。 在詢問您的同事之前，對您自己的代碼進行代碼審查。 有審閱者的心態，真正地檢查每一行代碼。

就個人而言，我喜歡註釋我自己的代碼審查，以更好地指導我的審查者。 這裡的目標是防止與可能缺乏關注有關的評論，並確保您遵循貢獻指南。 旨在提交代碼審查，就像您希望收到的一樣。

耐心點

提交代碼審查後，不要直接跳到一條新的私人消息中，要求您的審查者“看看，只需要幾分鐘”並間接渴望那個豎起大拇指的表情符號。 試圖催促你的同事完成他們的工作並不是一種健康的心態。 相反，請相信你同事的工作流程，因為他們相信你會提交一份好的代碼審查。 同時，等待他們有空時與您聯繫。 不要將您的評論者視為瓶頸。 記住要有耐心，因為困難的事情需要時間。

做一個傾聽者

一旦提交了代碼審查，就會出現評論，提出問題並提出更改。 這裡的黃金法則是不要將任何反饋視為人身攻擊。 請記住，任何代碼都可以從外部角度受益。

不要將您的評論者視為敵人。 相反，請利用這一刻放下自我，接受自己犯的錯誤，並願意向同事學習，以便下次可以做得更好。

作為審稿人

提前計劃

當你被要求成為審稿人時，不要馬上打斷事情。 這是我經常看到的一個常見錯誤。 審查代碼需要您全神貫注，每次切換代碼上下文時，您都會浪費時間重新調整注意力，從而降低工作效率。 相反，通過分配一天中的時間段來進行代碼審查來提前計劃。

就個人而言，我更喜歡在早上或午餐後在選擇任何其他任務之前先進行代碼審查。 這對我來說最有效，因為我的大腦仍然很新鮮，沒有以前的代碼上下文可以關閉。 除此之外，一旦我完成了審查，我可以專注於自己的任務，而作者可以根據反饋重新評估代碼。

給予支持

當拉取請求不遵循貢獻指南時，請給予支持——尤其是對新手。 以此為契機，指導作者改進他/她的貢獻。 同時，試著理解為什麼作者一開始就沒有遵循這些指導方針。 也許還有一些你以前不知道的改進空間。

檢查分支並運行它

在審查代碼時，讓它在您自己的計算機上運行——尤其是當它涉及用戶界面時。 這個習慣將幫助您更好地理解新代碼並發現如果您只是在瀏覽器中使用默認的 diff-tool 可能會錯過的東西，這將您的審查範圍限制在更改的代碼（沒有代碼編輯器中的完整上下文） .

假設前詢問

當你不明白某事時，不要害怕說出來並提出問題。 詢問時，請記住先閱讀周圍的代碼，避免做出假設。

大多數問題都屬於這兩種類型：

1. “如何”問題
   當你不明白某件事是如何工作的或它做了什麼時，如果代碼足夠清晰，請與作者一起評估。 不要把簡單的代碼誤認為是無知。 難讀的代碼和你不知道的代碼是有區別的。 樂於學習和使用新的語言功能，即使您還沒有深入了解它。 但是，僅當它簡化了代碼庫時才使用它。
2. “為什麼”問題
   當你不明白“為什麼”時，不要害怕建議對代碼進行註釋，尤其是在它是邊緣情況或錯誤修復的情況下。 在解釋它的作用時，代碼應該是不言自明的。 評論是對解釋某種方法背後的原因的補充。 就可維護性而言，解釋上下文非常有價值，它可以避免人們刪除認為無用的代碼塊。 （就個人而言，我喜歡對代碼進行評論，直到我覺得以後可以放心地忘記它為止。）

建設性的批評

一旦你找到了一段你認為應該改進的代碼，永遠記得要承認作者為項目做出貢獻的努力，並以一種接受和透明的方式表達自己。

• 公開討論。
  避免將您的反饋形式化為命令或指責，例如“您應該……”或“您忘記了……”。 將您的反饋表達為公開討論，而不是強制性要求。 記得評論代碼，而不是作者。 如果評論不是關於代碼的，那麼它不應該屬於代碼審查。 如前所述，支持。 使用被動語態、以復數形式交談、表達問題或建議是強調與作者同理心的好方法。
  

而不是“從這裡提取這個方法……”更喜歡“應該提取這個方法……”或“你覺得提取這個方法怎麼樣……”

• 清楚。
  反饋很容易被誤解，尤其是在表達意見與分享事實或指導方針時。 永遠記得在你的評論中立即清除。

不清楚：“這段代碼應該是……”

意見：“我相信這段代碼應該是……”

事實：“按照 [我們的指導方針]，這段代碼應該是……”。

• 解釋為什麼。
  對你來說很明顯的東西，可能對其他人來說並不明顯。 它永遠不會過多地解釋您的反饋背後的動機，因此作者不僅了解如何更改某些內容，而且了解它的好處是什麼。

意見：“我相信這段代碼可能是……”

解釋：“我相信這段代碼可能是（……），因為這將提高可讀性並簡化單元測試。”

• 提供例子。
  在分享作者不熟悉的代碼功能或模式時，請以參考作為指導來補充您的建議。 如果可能，請超越 MDN 文檔並分享適用於當前代碼場景的片段或工作示例。 如果編寫的示例過於復雜，請給予支持，並親自或通過視頻通話提供幫助。

除了說諸如“使用過濾器將幫助我們[動機]”之類的話，還要說，“在這種情況下，它可能是這樣的：[代碼片段]。 您可以查看 [Finder.js 中的示例]。 如有任何疑問，請隨時在 Slack 上聯繫我。”

• 講道理。
  如果多次出現相同的錯誤，最好只留下一條評論，並記住作者在其他地方也對其進行審查。 添加多餘的註釋只會產生噪音，並且可能會適得其反。

保持焦點

避免提出與當前代碼無關的代碼更改。 在提出改變建議之前，問問自己當時是否絕對有必要。 這種類型的反饋在重構中尤其常見。 這是我們作為一個團隊需要在效率和有效性之間做出的眾多權衡之一。

當談到重構時，就個人而言，我更傾向於小而有效的改進。 這些更容易審查，並且在使用目標分支更新分支時發生代碼衝突的可能性較小。

設定期望

如果您將代碼審查半途而廢，請讓作者知道，這樣時間預期就會受到控制。 最後，還要讓作者知道您是否同意新代碼，或者您是否想稍後再重新審查它。

在批准代碼審查之前，問問自己是否對將來接觸該代碼的可能性感到滿意。 如果是，這表明您進行了成功的代碼審查！

學會拒絕代碼審查

儘管沒有人承認這一點，但有時您不得不拒絕代碼審查。 當您決定接受代碼審查但試圖匆忙進行時，項目的質量以及您團隊的心態都會受到影響。

當你接受審查別人的代碼時，那個人就信任你的能力——這是一種承諾。 如果您沒有時間成為審稿人，請對您的同事說不。 我真心的; 不要讓您的同事等待永遠不會完成的代碼審查。 記得溝通並保持明確的期望。 對你的團隊誠實，甚至對你自己誠實。 無論您選擇什麼，都要健康地做，並且做對。

結論

如果有足夠的時間和經驗，進行代碼審查將教給您的不僅僅是技術知識。 您將學會給予和接受他人的反饋，並在做出決定時投入更多思考。

每次代碼審查都是作為一個社區和個人成長的機會。 即使在代碼審查之外，也要記住培養一種健康的心態，直到有一天它對你和你的同事來說自然而然。 因為分享讓我們變得更好！

關於 SmashingMag 的進一步閱讀：

• 一起工作：設計師和開發人員如何溝通以創建更好的項目
• 通過將設計師帶入代碼審查過程來更好地協作
• 網頁設計師和開發人員應該聽哪些播客？
• 如何製作完美的 Web 開發人員簡歷