當審查拉取請求時，我看到了完成要求並立即獲得批准的漂亮代碼。
我也見過長輪來回，要求改變。令人困惑或過於努力的代碼。
這是我作爲高級工程師和技術主管在代碼審查中尋找的東西。我也嘗試讓我自己的代碼符合這些標準。
尺寸
乍一看，我對拉取請求的最初反應是：
“改變了多少？”
有兩個原因：
- 第一個是自私的。我需要知道 PR 審覈需要 10 分鐘還是一個小時。如果你的 PR 真的很大，我可能需要稍後再審覈。如果您想要快速審查，請瞄準更短的 PR。
- 第二個是思考變革管理。當您對代碼庫進行重大更改時，出錯的機會就會增加。通常，對於大型拉取請求，您可以通過多種方式分階段單獨發佈部分代碼。這些類型的增量更改更可取。
教訓是讓你的拉取請求儘可能小。根據需要，創建從初始 PR 分支出來的後續 PR，以允許按順序發佈代碼。
測試
接下來，我查看拉取請求是否包含測試。測試應該清楚地展示新代碼的行爲和預期結果。
我將嘗試考慮可能尚未測試的邊緣案例並對其發表評論。作爲 CI/CD 的一部分，我鼓勵我工作的團隊針對存儲庫運行代碼覆蓋率，以確保所有新代碼都經過測試。
測試幫助我作爲審閱者理解代碼。在我看來，它們在合併任何代碼之前也是必不可少的。
結構
現在我已準備好查看新的邏輯代碼，我將從評估解決方案的整體結構開始。
因爲我只是查看了測試，所以我對代碼如何協同工作來解決問題有一個想法。我將瀏覽已承諾回答一些問題的文件、類、函數等：
- 這個新代碼的位置有意義嗎？
- 它使用邏輯類結構嗎？它應該從某個現有類繼承還是以某種方式共享邏輯？
- 函數和類的參數是否合乎邏輯且命名合理？
- 函數返回什麼？這有意義嗎？
- 我們可以簡化實現的結構嗎？
邏輯
解決了這些大問題後，我將深入研究代碼的實際內容。
在我工作過的大多數團隊中，我們使用靜態分析工具來自動檢查代碼質量。這些工具可以解決大部分明顯的錯誤、安全漏洞和低效問題。有一個自動的第一次通過並知道你正在審查的任何 PR 至少滿足一個基本閾值是很有用的。
當我評估一個函數或類時，我會按以下順序尋找一些關鍵的東西：
- 是否有意義？— 如果不是，那就是危險信號。這意味着代碼比它需要的更復雜。
- 浪費嗎？— 培養算法複雜性的直覺是一項困難但有用的技能。通常，這意味着一些簡單的事情，比如使用字典而不是列表，只迭代一次並記住結果，或類似的事情。
- 它可以更簡單/更清潔嗎？— 看到一條不必要的線路或一種可以更簡單地做某事的方法並不少見。在大多數情況下，將其歸因於開發人員連續數小時處理同一問題 — 無法發現錯誤，因爲他們已經在問題中待了很長時間。
命名
新代碼文檔的第一行是很好的命名。
我所有的代碼審查都包括我思考變量、函數和類名稱是否有意義的部分。我們可以使用更短的名稱嗎？所有名稱是否都清楚地傳達了它們是什麼或它們做什麼？
我的一個規則是沒有縮寫。雖然他們現在看起來很聰明，但隨着時間的推移，他們會變得站不住腳。所有的名字都需要拼寫出來並清楚它們的意思。
命名是軟件開發中最困難的部分之一。
文檔
最後，我檢查代碼是否有適當的文檔。
我並不是說開發人員需要編寫有關代碼及其作用的段落。只是每一段代碼都應該有一個簡單的描述它是如何工作的。
例如，在 Python 中，我們使用文檔字符串來做到這一點。每個新函數或類都需要有一個文檔字符串。在 JavaScript 中，出於同樣的目的，我在函數定義之前使用了內聯註釋。
我還鼓勵團隊爲他們的參數和返回值使用類型。類型註釋是我尋找的另一份文檔。
適當的文檔還意味着在您更改內容時更新現有文檔。在代碼審查中，我試圖提醒開發人員在過時時更新文檔字符串和註釋。
另一大塊是外部文檔。如果更改影響外部 API，則需要使用新信息更新 API 文檔。
未來 PR 的清單
希望本文爲您提供了尋找內容的良好基礎。當您提交自己的代碼以供審查時，您可以將其用作清單，以確保在請求他人審查之前您已涵蓋所有內容。
當您進行自己的審查時，請隨意使用它作爲分析其他人代碼的指南。
如果你喜歡我的文章，點贊，關注，轉發！