項目代碼審查

一、為什麼要代碼審查？

代碼審查（英語：Code review）是指對計算機源代碼系統化地審查，常用軟體同行評審的方式進行，其目的是在找出及修正在軟體開發初期未發現的錯誤，提升軟體品質及開發者的技術。代碼審查常以不同的形式進行，例如結對程式設計、非正式的看過整個代碼，或是正式的軟體檢查。

Code Review 的首要目的是改善和保證代碼品質，預防 bug，也是熟悉軟體架構，了解軟體業務邏輯的好方法。此外還有益于制定團隊代碼規範，形成團隊技術氛圍，加深技術團隊成員溝通，老帶新互助成長等等。有些團隊裡 Code Review 處于開發流程的邊緣位置，有些團隊 Code Review 處于代碼編寫到部署的必經部分。對于我們來說，Code Review 是代碼編寫到部署的必經部分，所有代碼都必須經過 Review 才能 merge。

二、Code Review 怎麼做？

要做代碼審查，有資深開發、進階開發、中級開發、初級開發四個級别崗位都在寫代碼。是讓資深審查進階開發的代碼、進階審中級、中級審初級好呢？還是讓資深審中級、進階審初級的代碼好呢？

二、Code Review 分類

代碼審查的四種方式：

參考連結：https://blog.csdn.net/ywl570717586/article/details/89916025

三、Code Review 實用性操作

1、對事不對人

大家是同僚，在一個團隊工作和氣很重要，不要在 Code Review 中說“你寫的什麼垃圾東西這種話”，你可以說“這個變量名不好了解，咱們換成巴拉巴拉是不是更好”。

2、每個 Review 至少給一條正面評價

Code Review 本意是改善代碼品質，增強團隊成員之間的溝通，但是我一送出代碼就有人說我寫的垃圾，這很打擊自信心啊，也不利于團隊成員和平相處。代碼有問題，指出問題是必須的，要實事求是，但是有的時候也需要給隊友一點鼓勵，例如簡單的 或者“贊一個”我都很開心了。

3、保證釋出的代碼和評審意見的可讀性

大家都是程式員，你送出代碼的時候，在符合團隊風格的同時，把代碼弄的好看點，如果你明确自己這個代碼哪個地方不足，Highlight 出來讓大家給意見。如果你是來 Review 代碼的，把意見寫的通順點，評論有條理一些。對反引号 (`) 嵌入代碼或三個反引号 (```) 寫代碼塊，這樣看的舒服得多，效率也高。

4、用工具進行基礎問題的自動化檢查

用 Tab 還是空格，用兩個空格還是四個空格，函數後面怎麼換行等基礎問題檢查，可以使用 eslint 和Rubocop 等類似的工具進行，團隊成員應該把更多精力放在代碼規範，代碼性能優化等地方。

5、全員參加 Code Review

并設定各部分負責人。擴大 Code Review 參與面，參與不是說一定去稽核别人的代碼，可以是代碼被稽核，也可以是看别人稽核意見，這都是學習的過程。并且每部分設定負責人，該負責人對這部分代碼品質負責，負責人需要是資深工程師。全員參與 Code Review 可以讓團隊成員更快的成長，新人在看大佬 Review 代碼的過程就能學到很多。

6、每個代碼 PR 内容一定要少

Code Review 效果和品質與 PR 代碼量成反比，你一下送出這麼多代碼，我今天還下不下班了？ 我女朋友你幫我陪？每次 PR 代碼量小一些，看起來速度快，又不至于失去耐心，這樣才能達到 Code Review 的效果，是以要經常進行 Code Review，但是每個 PR 代碼量要少。我建議要少于 300 行/PR。

7、在寫新代碼之前，先 Review 掉需要評審的代碼

你讓我去 Review 一周前的代碼？我還得把思維和項目進度切換到一周前？大家肯定不願意，是以要形成規定，寫新代碼之前先把舊的 Review 掉，送出 PR 的時候也保證代碼量小，這樣 Review 起來不需要大塊時間，改起來也快。不能因為 Code Review 大幅耽誤項目進度，進度是全團隊的事，不是某個人的事。

8、 如果你有更好的方案，盡管提出來

在 Code Review 中經常會發現寫的不好的地方，如果你有更好的方法，歡迎提出來！首先能改進這個 PR 的代碼，其次能展現你的能力，團隊應該定期對這種提出好的解決方案的同僚進行獎勵。

9、不要在 review 中讨論需求，review 就是 review

不要在 Code Review 裡搞别的，有需要就另安排時間進行，要明确 Code Review 是完善代碼，不是需求和功能讨論，始終要以代碼品質為中心。

推薦Code Review 工具

Crucible： Atlassian 内部代碼審查工具；

連結：https://www.atlassian.com/zh/software/crucible

Gerrit： Google 開源的 git 代碼審查工具；

連結：https://www.gerritcodereview.com/

GitHub/GitLab： 程式員應該很熟悉了，上面的 “Pull Request” 在代碼審查這裡很好用；

連結：這個大家都使用就不發連結了。

LGTM： 可用于 GitHub 和 Bitbucket 的 PR 代碼安全漏洞和代碼品質審查輔助工具；

連結：https://lgtm.com/

Phabricator： Facebook 開源的 git/mercurial/svn 代碼審查工具；

連結：https://www.phacility.com/phabricator/

PullRequest： GitHub pull requests 代碼審查輔助工具；

連結：https://www.pullrequest.com/

Pull Reminders： GitHub 上有 PR 需要你稽核，該插件自動通過 Slack 提醒你；

連結：https://pullreminders.com/

Reviewable： 基于 GitHub pull requests 的代碼審查輔助工具；

連結：https://reviewable.io/

Sider： GitHub 自動代碼審查輔助工具；

連結：https://sider.review/

Upsource： JetBrain 内部部署的 git/mercurial/perforce/svn 代碼審查工具。

連結：https://www.jetbrains.com/upsource/

原文内容連結：https://www.zhihu.com/question/20046020/answer/555007256