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

Brent Beer, Peter Bell發表於2017-09-10

通過使用 GitHub 的拉取請求Pull Request正確地進行程式碼稽核，把時間更多的花在構建上，而在修復上少用點時間。

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

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

程式碼審查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中國 榮譽推出

相關文章