如何使用拉取請求（PR）來改善你的代碼審查

如果你不是每天編寫代碼，你可能不知道軟體開發人員日常面臨的一些問題。

• 代碼中的安全漏洞
• 導致應用程序崩潰的代碼
• 被稱作 「技術債務」 和之後需要重寫的代碼
• 在某處你所不知道地方的代碼已經被重寫

代碼審查 Code review 可以允許其他的人或工具來檢查代碼，幫助我們改善所編寫的軟體。這種審查（也稱為 同行評審 peer review ）能夠通過自動化代碼分析或者測試覆蓋工具來進行，是軟體開發過程中兩個重要的部分，它能夠節省數小時的手工工作。同行評審是開發人員審查彼此工作的一個過程。在軟體開發的過程中，速度和緊迫性是兩個經常提及的問題。如果你沒有儘快的發布，你的競爭對手可能會率先發布新功能。如果你不能夠經常發布新的版本，你的用戶可能會懷疑您是否仍然關心改進你的應用程序。

權衡時間：代碼審查與缺陷修復

如果有人能夠以最小爭議的方式彙集多種類型的代碼審查，那麼隨著時間的推移，該軟體的質量將會得到改善。如果認為引入新的工具或流程最先導致的不是延遲，那未免太天真了。但是代價更高昂的是：修復生產環境中的錯誤花費的時間，或者在放到生產環境之前改進軟體所花費的時間。即使新工具延遲了新功能的發布和得到客戶欣賞的時間，但隨著軟體開發人員提高自己的技能，該延遲會縮短，軟體開發周期將會回升到以前的水平，而同時缺陷將會減少。

通過代碼審查實現提升代碼質量目標的關鍵之一就是使用一個足夠靈活的平台，允許軟體開發人員快速編寫代碼，置入他們熟悉的工具，並對彼此進行同行評審。 GitHub 就是這樣的平台的一個很好的例子。然而，只是把你的代碼放在 GitHub 上並不會魔術般地使代碼審查發生；你必須使用 拉取請求 Pull Request 來開始這個美妙的旅程。

拉取請求：關於代碼的現場討論

拉取請求 Pull Request 是 Github 上的一個工具，允許軟體開發人員討論並提出對項目的主要代碼庫的更改，這些更改稍後可以部署給所有用戶看到。這個功能創建於 2008 年 2 月，其目的是在接受（合併）之前，對某人的建議進行更改，然後在部署到生產環境中，供最終用戶看到這種變化。

拉取請求開始是以一種鬆散的方式讓你為某人的項目提供更改，但是它們已經演變成：

• 關於你想要合併的代碼的現場討論
• 提升了所更改內容的可視功能
• 整合了你最喜愛的工具
• 作為受保護的分支工作流程的一部分可能需要顯式的拉取請求評審

對於代碼：URL 是永久的

看看上述的前兩個點，拉取請求促成了一個正在進行的代碼討論，使代碼變更可以更醒目，並且使您很容易在審查的過程中找到所需的代碼。無論是對於新人還是有經驗的開發人員，能夠回顧以前的討論，了解一個功能為什麼以這種方式開發出來，或者與另一個相關功能的討論相聯繫起來是無價的。當跨多個項目協調，並使每個人儘可能接近代碼時，前後討論的內容也非常重要。如果這些功能仍在開發中，重要的是能夠看到上次審查以來更改了哪些內容。畢竟，審查小的更改要比大的容易得多，但不可能全都是小功能。因此，重要的是能夠找到你上次審查，並只看到從那時以來的變化。

集成工具：軟體開發人員的偏執

再看下上述第三點，GitHub 上的拉取請求有很多功能，但開發人員總是偏好第三方工具。代碼質量是個完整的代碼審查領域，它涉及到其它組件的代碼評審，而這些評審不一定是由人完成的。檢測「低效」或緩慢的代碼、具有潛在安全漏洞或不符合公司標準的代碼是留給自動化工具的任務。類似 SonarQube 和 Code Climatecan 這樣工具可以分析你的代碼，而像 Codecov 和 Coveralls 的這樣工具可以告訴你剛剛寫的新代碼還沒有得到很好的測試。這些工具最令人稱奇的是，它們可以集成到 GitHub 中，並把它們的發現彙報到拉取請求當中！這意味著該過程中不僅是人們在審查代碼，而且工具也在會在那裡報告情況。這樣每個人都可以完全了解一個功能是如何開發的。

最後，根據您的團隊的偏好，您可以利用受保護的分支工作流的 必需狀態 required status 功能來要求進行工具審查和同行評審。

雖然您可能只是剛剛開始您的軟體開發之旅，或者是一位希望知道項目正在做什麼的業務利益相關者，抑或是一位想要確保項目的及時性和質量的項目經理，你都可以通過設置批准流程來參與到拉取請求中，並考慮集成更多的工具以確保質量，這在任何級別的軟體開發中都很重要。

無論是為您的個人網站，貴公司的在線商店，還是想用最新的組合以獲得最大的收穫，編寫好的軟體都需要進行良好的代碼審查。良好的代碼審查涉及到正確的工具和平台。要了解有關 GitHub 和軟體開發過程的更多信息，請參閱 O'Reilly 的 《GitHub 簡介》 一書， 您可以在其中了解創建項目、啟動拉取請求以及概要了解團隊的軟體開發流程。

作者簡介：

Brent Beer

Brent Beer 通過大學的課程、對開源項目的貢獻，以及擔任專業網站開發人員使用 Git 和 GitHub 已經超過五年了。在擔任 GitHub 上的培訓師時，他也成為 O』Reilly 的 《GitHub 簡介》的出版作者。他在阿姆斯特丹擔任 GitHub 的解決方案工程師，幫助 Git 和 GitHub 向世界各地的開發人員提供服務。

Peter Bell

Peter Bell 是 Ronin 實驗室的創始人以及 CTO。培訓是存在問題的，我們通過技術提升培訓來改進它！他是一位有經驗的企業家、技術專家、敏捷教練和 CTO，專門從事 EdTech 項目。他為 O'Reilly 撰寫了 《GitHub 簡介》，為代碼學校創建了「精通 GitHub 」課程，為 Pearson 創建了「 Git 和 GitHub 現場課」課程。他經常在國際和國際會議上發表 ruby、 nodejs、NoSQL（尤其是 MongoDB 和 neo4j ）、雲計算、軟體工藝、java、groovy、j 等的演講。

via: https://www.oreilly.com/ideas/how-to-use-pull-requests-to-improve-your-code-reviews

作者：Brent Beer, Peter Bell 譯者：MonkeyDEcho 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive