代碼檢查?可能是痛苦的。軟件工程師經(jīng)常抱怨評(píng)審過(guò)程緩慢，延遲下游任務(wù)，并導(dǎo)致在打開請(qǐng)求(PR)和下一個(gè)任務(wù)之間來(lái)回導(dǎo)航時(shí)上下文切換。代碼審查也可能充滿了吹毛求疵和自行車欺騙，使其成為每個(gè)參與者的糟糕經(jīng)歷。

為了解決這個(gè)問(wèn)題，一些工程師甚至建議我們完全去掉拉請(qǐng)求和代碼審查。雖然這可能適用于初創(chuàng)企業(yè)的小型團(tuán)隊(duì)，但我不認(rèn)為這對(duì)每個(gè)人都是正確的解決方案，尤其是企業(yè)級(jí)別的公司。

相反，我們有很多方法可以使代碼審查過(guò)程對(duì)于代碼作者和代碼審查者來(lái)說(shuō)都是一種更好的體驗(yàn)。讓我們一起考慮其中的七個(gè)最佳實(shí)踐。

1.盡量少要求

每個(gè)工程師都害怕審查修改了1000多行代碼的請(qǐng)求。這些評(píng)審可能需要幾個(gè)小時(shí)才能完成，通常最終發(fā)生的情況是，評(píng)審人員開始瀏覽代碼，而不是仔細(xì)地評(píng)審代碼。

解決方案是保持您的拉請(qǐng)求很小。小型公關(guān)更容易、更快地進(jìn)行評(píng)審，因?yàn)樵u(píng)審人員不需要花費(fèi)那么多時(shí)間建立一個(gè)關(guān)于所有變更如何協(xié)同工作的心理模型。代碼更改也更少，這可能意味著更少的錯(cuò)誤、更少的注釋以及作者和審閱者之間更少的來(lái)回。

保持你的公關(guān)規(guī)模小起初可能看起來(lái)很困難，但是如果你把你的工作分解成小任務(wù)并保持專注，這是可以做到的。在實(shí)現(xiàn)新特性或修復(fù) bug 的同時(shí)，不要進(jìn)行重大重構(gòu)。在代碼中使用特性標(biāo)志，這樣就可以將新特性的一小部分合并到主分支中，而不會(huì)在生產(chǎn)應(yīng)用程序中顯示出來(lái)。

保持你的PRs小。你的審查員會(huì)感激你的。

2.使用拉請(qǐng)求模板

另一個(gè)麻煩是要求在沒(méi)有任何上下文的情況下檢查拉請(qǐng)求。當(dāng)一個(gè)公關(guān)人員無(wú)緣無(wú)故地出現(xiàn)在你面前時(shí)，你經(jīng)常會(huì)想: “這個(gè)公關(guān)是干什么的？這是在解決什么問(wèn)題？是否有與此相關(guān)的任務(wù)？為什么要采取這種特殊的方法?”

Pull 請(qǐng)求模板是一個(gè)小型的、可配置的表單，您可以將其設(shè)置為每個(gè)新 pull 請(qǐng)求上的默認(rèn)文本。PR 模板提示代碼作者為其 PR 提供相關(guān)細(xì)節(jié)。通常情況下，公關(guān)模板會(huì)要求簡(jiǎn)要描述您所做的工作以及為什么要這樣做，任務(wù)票據(jù)的鏈接，以及驗(yàn)證更改的測(cè)試計(jì)劃。

好的公關(guān)模板通常還包括一個(gè)簡(jiǎn)短的清單，供代碼作者檢查，以確保他們沒(méi)有遺漏任何基本內(nèi)容。此檢查表可能包括單元測(cè)試、文檔、國(guó)際化、跨瀏覽器支持和可訪問(wèn)性等項(xiàng)目。

下面是一個(gè)例子拉請(qǐng)求模板，我喜歡使用的所有我的回購(gòu)協(xié)議:

拉請(qǐng)求模板示例

3.實(shí)現(xiàn)響應(yīng)時(shí)間 SLA

如果您發(fā)現(xiàn)拉請(qǐng)求未被審查的時(shí)間比您希望的要長(zhǎng)，那么現(xiàn)在是一個(gè)好時(shí)機(jī)，作為一個(gè)團(tuán)隊(duì)來(lái)設(shè)置對(duì)新的拉請(qǐng)求應(yīng)該被審查的速度的預(yù)期。換句話說(shuō)，一個(gè)公關(guān)在被提取之前最多可以存在多長(zhǎng)時(shí)間: 一個(gè)小時(shí)？?jī)蓚€(gè)小時(shí)？24小時(shí)？你對(duì)這個(gè)問(wèn)題的回答很可能取決于你團(tuán)隊(duì)的規(guī)模。對(duì)于來(lái)自團(tuán)隊(duì)的內(nèi)部拉動(dòng)請(qǐng)求和來(lái)自其他團(tuán)隊(duì)的外部拉動(dòng)請(qǐng)求，您可能有不同的答案。

在選擇響應(yīng)時(shí)間 SLA (服務(wù)水平協(xié)議)時(shí)，您需要找到正確的平衡。當(dāng)你發(fā)布一個(gè)新的公關(guān)時(shí)，期望每個(gè)人都立即放下手頭的工作并審查你的代碼是不合理的，但是你也不希望公關(guān)連續(xù)幾個(gè)小時(shí)都沒(méi)有被審查。找到正確的平衡，讓你的隊(duì)友進(jìn)入流動(dòng)狀態(tài)。他們應(yīng)該能夠處理自己的代碼，然后在一天中的自然停止點(diǎn)檢查 PR。

就個(gè)人而言，我喜歡對(duì)內(nèi)部團(tuán)隊(duì)公關(guān)有兩小時(shí)的響應(yīng)時(shí)間，對(duì)外部團(tuán)隊(duì)公關(guān)有24小時(shí)的響應(yīng)時(shí)間。

不管你和你的隊(duì)友做出什么決定，擁有一個(gè)團(tuán)隊(duì)協(xié)議可以讓你們彼此負(fù)責(zé)。如果每個(gè)人都同意一個(gè)特定的 SLA，并且時(shí)間已經(jīng)過(guò)去了，你的公關(guān)之一，你知道這是可以開始竊聽(tīng)人們關(guān)于它。

4.培訓(xùn)初級(jí)和中級(jí)工程師

培訓(xùn)機(jī)會(huì)無(wú)處不在。指導(dǎo)經(jīng)驗(yàn)不足的工程師不僅僅是教他們正在使用的技術(shù)和語(yǔ)言。它還包括教他們軟技能，比如如何進(jìn)行有效的代碼審查。

在代碼檢查過(guò)程中，教會(huì)您的隊(duì)友您所尋找的東西。幫助他們明白什么是重要的，什么是不重要的。教他們?nèi)绾卧诖a評(píng)審注釋中有效地交流，比如在非阻塞建議前面加上“ nit”

有大量關(guān)于如何成為一個(gè)更有效的代碼審查員的資源。谷歌的代碼審查開發(fā)人員指南值得一讀。該指南對(duì)代碼作者和代碼審查者都有很好的建議。對(duì)于一個(gè)更厚顏無(wú)恥的資源，如何讓你的代碼審查員愛(ài)上你很容易是一些最好的(和有趣的)建議，為開發(fā)人員創(chuàng)建拉請(qǐng)求。

5.建立連續(xù)集成管道

當(dāng)大多數(shù)注釋是“丟失分號(hào)”或“這里似乎沒(méi)有縮進(jìn)”時(shí)，代碼檢查就變得乏味不要在代碼檢查期間花費(fèi)時(shí)間在代碼格式化程序和代碼行程序可以為您處理的事情上。讓計(jì)算機(jī)自動(dòng)處理瑣碎的事情，這樣你就可以專注于需要人力的重要事情。

對(duì)于 JavaScript 項(xiàng)目，為回購(gòu)配置一個(gè)像 Prettier 這樣的格式化程序和一個(gè)像 ESLint 這樣的行程很簡(jiǎn)單。然后，您可以使用諸如 Travis CI、 CircleCI、 GitHub Actions 或 GitLab CI/CD 之類的工具為回購(gòu)建立持續(xù)集成。

CI 管道將為您運(yùn)行這些格式化和連接任務(wù)以及單元測(cè)試。如果 CI 管道在請(qǐng)求的任何一個(gè)步驟中失敗，它將阻止合并該請(qǐng)求。

現(xiàn)在您已經(jīng)自動(dòng)完成了代碼審查的幾個(gè)重要部分，從而節(jié)省了您的時(shí)間。

6.使用拉請(qǐng)求審查應(yīng)用程序

有時(shí)候，不僅需要檢查請(qǐng)求中的代碼，還需要手動(dòng)查看應(yīng)用程序中的更改，以驗(yàn)證情況是否良好。對(duì)于具有復(fù)雜設(shè)置步驟的應(yīng)用程序，下拉其他人的代碼并在您的計(jì)算機(jī)上本地運(yùn)行它可能需要5分鐘到1小時(shí)。頭好痛！

每當(dāng)創(chuàng)建一個(gè)新的 PR 時(shí)，拉請(qǐng)求審查應(yīng)用程序都會(huì)自動(dòng)將代碼部署到一個(gè)短暫的測(cè)試環(huán)境中。這使得評(píng)審員可以輕松地檢查 UI 更改，而不必下拉代碼并在他們的機(jī)器上本地運(yùn)行。這不僅節(jié)省了時(shí)間，而且還促使評(píng)審人員在評(píng)審時(shí)更加全面，使其更加容易。

7.生成可視化代碼更改的圖表

在 GitHub 或 GitLab 中查看代碼時(shí)，文件通常以字母順序顯示。對(duì)于相對(duì)較小的公共關(guān)系，這可能不是一個(gè)問(wèn)題。但是當(dāng)一個(gè)公關(guān)涉及到幾十個(gè)文件時(shí)，有時(shí)候看到這些變化有邏輯地組合在一起是很有幫助的，這樣你就可以看到它們是如何在一個(gè)更大的圖片中組合在一起的。

CodeSee 查看地圖幫助您可視化哪些文件被更改，以及這些更改如何影響它們的上游或下游依賴關(guān)系。它們與 GitHub 集成，可以自動(dòng)在您的 PR 上發(fā)布評(píng)論和圖表。您甚至可以創(chuàng)建代碼的交互式導(dǎo)覽，以幫助指導(dǎo)代碼審查人員。最棒的是，CodeSee Maps 對(duì)開源組織及其公共存儲(chǔ)庫(kù)是免費(fèi)的。

CodeSee 映射?