在過去的三年中，我已經審查了1000多個拉（合併）請求。在那段時間裡，我學到了很多東西–主要是關於如何不審閱程式碼，如何減輕過程的痛苦，使高質量的程式碼產生什麼等等。

拉取請求只需要做一件事

最好的辦法是將請求合併成有意義的部分–一個請求只能解決一件事。

在進行程式碼審查時，您需要牢記很多事情。“這背後的意圖是什麼？” ，“這如何與其餘程式碼保持一致？” 和“效果會很好嗎？”。

當您有一個集中的拉式請求試圖解決一個問題時，其中一些問題將變得更容易回答。

另一個重要方面是拉取請求的大小。更大的請求需要成倍增加的時間來審查。當我知道需要花15分鐘以上的時間時，您將不得不等待幾個小時。

較大的拉取請求也會有更多的錯誤，因此獲得批准的時間也會大大增加。這意味著您可能需要等待幾天才能獲得批准的程式碼。而且，如果您的公司敏捷，那將增加合併痛苦的機會，而這僅僅是痛苦的。

自動化儘可能多的檢查

審閱者必須牢記很多事情，其中​​還包括檢查程式碼格式，是否存在適當的文件，可通過的測試等。我記得當時我不得不考慮所有這些因素，那是分散時間和精力的時間。

解決方案非常簡單–將所有檢查整合到CI管道中。基本上，每當有人提交拉取請求時，它就會執行所有檢查，並且不允許在所有檢查通過之前合併。作為審閱者，您將不必擔心再次格式化。

自動化測試有助於確保作者沒有破壞任何東西，並且測試仍在通過中。根據您的測試方法，這很容易成為您的拉取請求CI中最重要的檢查。

與作者坐在一起檢查程式碼

因為您能夠與作者一起快速遍歷程式碼並分享您的觀點，所以它使稽核過程更快。作者還可以更好地解釋其方法背後的原因，例如是否嘗試過某些東西以及為什麼它不起作用。

因為您能夠與作者一起快速遍歷程式碼並分享您的觀點，所以它使稽核過程更快。作者還可以更好地解釋其方法背後的原因，例如是否嘗試過某些東西以及為什麼它不起作用。

寫評論時要體諒

如果您比程式碼的編寫者更有經驗，則需要考慮您怎麼說的事情很重要。寫得很好的批評可以使開發人員在將來變得更好，但也可能破壞某人的夢想。

我發現最有效的方法是提出開放性問題–這不是激進的，甚至鼓勵開發人員進行批判性思考。這是否會比告訴別人解決方案花費更多時間？是的，短期的。但是從長遠來看，您正在幫助他們成長，他們重犯錯誤的可能性較小。

因此，下次有人在for迴圈中而不是在迴圈之前開啟檔案時，沒有明確指出，而是問“您如何在這裡降低複雜性？”。這將意味著很多。

新增一個名為我在本地執行此程式碼的標誌

最讓我感到困擾的是，在一些小的請求中發現了一個錯誤，因此該功能根本無法正常工作。這意味著開發人員甚至沒有執行程式碼-可能認為沒有必要，因為更改很小。

發生幾次之後，我新增了一個標記，稱為“ 我在本地執行此程式碼”，從而完全解決了問題。我停止審查不在本地執行的程式碼。

這是我們的模板，每個開發人員在建立拉取請求時必須填寫：

合併請求說明

• 有什麼新東西？
  • 已實施...
• 有什麼變化？
  • 變了...

檢查清單

• []我在本地執行此程式碼
• []我寫了必要的測試
• []我用型別提示覆蓋了我的程式碼
• []我更新了CHANGELOG

Trello卡

https://trello.com/c/

應該知道

• 還有什麼應該知道的嗎？
• 有部署說明嗎？
• 還有其他檔案嗎？