8 個 Tips 讓你更好的進行 Code Review

摘要： Code Review 能夠提升代碼質量。

• 原文：Elevenbeans
• 做者：前端小智

Fundebug經受權轉載，版權歸原做者全部。

原文地址：https://kellysutton.com/2018/10/08/8-tips-for-great-code-reviews.html 更多內容請見譯者 Blog：https://github.com/elevenbeans/elevenbeans.github.io

你在學校裏未曾學到的東西中有一件是：如何才作出優秀的 Code Review。你學到了算法、數據結構、編程語言基礎知識，但沒有人坐下來講：「下面介紹如何確保你如何（對同事）提出很棒的反饋（Code Review）」。

Code Reviews 是開發出好軟件的關鍵過程。通過審覈的代碼每每質量較高、錯誤較少。一個良性的 Code Reviews 文化也提供了額外的好處：

1. Ta 能夠對於 bus factor (和 key person risk 相近，意爲少數關鍵的技術人員帶隊，一旦人才流失對團隊是很大打擊，團隊抗風險能力弱)進行有效限制；
2. Ta 是培訓新成員的一個很好的工具；
3. Ta 也是共享知識的好方法

假設

在咱們深刻研究以前，爲這篇文章中的要點作一些假設是很重要的。 它們以下：

• 你在信任的環境中工做，或者您和您的團隊正在努力提升你對他們的信任度；
• 您應該可以在非代碼方案中提供反饋，或者正在努力在您的團隊中提供反饋；
• 你的團隊但願產生更好的代碼，而且理解完美是動詞而不是形容詞。 咱們明天可能會找到一種更好的作事方式，咱們須要保持開放的心態；
• 你的公司重視高質量的代碼，並理解業務可能不會快速「交付」。用引號是由於未經測試和未經審覈的代碼實際上可能沒法正常工做；

如今咱們已經制定了一些基本規則，讓咱們深刻研究。

1. 咱們是人類

很好理解，你即將審覈的代碼中，有人花了時間、付出了心血。他們會但願本身的代碼寫的很棒。你的同事會表現出最好的意圖，沒有人願意發送蹩腳的代碼。

保持客觀是很是困難的。你須要始終確保批評代碼自己，並嘗試理解編寫代碼的上下文。儘量多地取消除區隔。而不是說：

你以一種使人困惑的方式寫了這個方法。

請嘗試從新改寫代碼自己以及從新理清對 Ta 的理解：

這個方法讓我有點困惑，咱們能爲這個變量找到一個更好的名字嗎？

這裏，咱們會解釋咱們做爲讀者對代碼的見解。這不是他們的行爲或意圖。這是關於咱們和咱們對代碼的解釋。

每一個 PR 都是它本身的艱難對話。嘗試與您的同事達成共識，共同努力實現更好的代碼。

若是您剛剛結識了同事，而且您對 PR 有重要反饋，請一塊兒瀏覽代碼。這將是一個與同事創建關係的好機會。與每位同事一塊兒作到這一點，直到這件事情讓你再也不感受尷尬。

2. 自動化

若是計算機能夠決定並執行規則，請讓計算機執行此操做。無休止地爭論 Space 與 Tab 並不能充分利用時間、提升任何效率。相反，應該花時間對於規則達成一致意見。在低風險情景中，這有機會可讓你瞭解你的團隊在 **「不認同但承諾」**方面的表現。

語言和現代工具鏈不缺少執行規則（linting）和複用它們的方法。 在 Ruby 中，你有 Rubocop; 在 JavaScript 中，Jslint/eslint。 找到你的語言的 linter 並將其插入你項目的構建流程。

若是您發現缺乏現有的 linter，請本身編寫！ 編寫本身的規則很是簡單。 在 Gusto 中，咱們使用自定義的 linter 規則來捕捉類的棄用或溫和地提醒人們遵照一些 Sidekiq 的最佳實踐。

3. 全員參與

將全部代碼審查職責一股腦全交給 Shirley 是很誘人的。

Shirley 是一個關於代碼的大師，她老是知道什麼是最好的。她知道系統的前因後果，並且她在公司工做的時間超過了團隊的集體任期。

然而，僅僅由於 Shirley 理解某些事情並不意味着她的團隊中的其餘人能夠理解。年輕的團隊成員可能會對指出 Shirley 的代碼評論的問題而猶豫不決。

我發現將評論分發給團隊的不一樣成員會產生更健康的團隊互動和更好的代碼。初級工程師在代碼審查中最強大的一句是「我發現這使人困惑。」這些就是使代碼更清晰，更簡單的機會。

請傳播這些評論。

4. 增長可讀性

在 Gusto，咱們使用 GitHub 來管理咱們的代碼項目。幾乎 GitHub 上的每一個<textarea>都支持Markdown，這是一種在評論中添加 HTML 格式的簡單方法。

擁抱 Markdown 是讓事物變得可讀的好方法。GitHub 或您選擇的工具可能具備語法突出顯示，這對於刪除一些代碼片斷很是有用。使用內聯代碼的單反引號（`）或代碼塊的三重反引號（```）能夠更好地傳達想法。

熟悉 Markdown 語法，特別是在註釋中編寫代碼時。 這樣作有助於保持您的評論具體和專一。

5. 至少留下一個積極評論

代碼評論本質上是負面的事情。在我要將此代碼發佈到線上環境以前告訴我這個代碼有什麼問題，這是挺傷人的事兒。有人花時間在這上面，並指望你會指出它會如何變得更好。

所以，請至少留下一個積極的評論。讓它變得有意義和極具個性。若是有人終於掌握了他們一直在努力的掌握的事情，那麼就請你把它 Ta 出來。 它能夠像點個贊 👍 或 「喜歡這個」 同樣簡單。

在每次 Code Review 中留下一些正面的內容都是微妙的提示：咱們是在一塊兒合做。若是咱們生產出更好的代碼，咱們都會受益。

6. 提供替代方案

一些我嘗試作的事情是（尤爲是在和那些只是學習語言或框架的人合做的時候）：提供替代方案。

當心這個。若是表達不正確，它可能會變得傲慢或自私：「這就是我作的方式」。請儘可能保持客觀，並討論你提供的替代方案的利弊權衡。作得好，這應該有助於擴展每一個人對手頭技術的瞭解。

7. 響應時間是關鍵

Code Review 過程快速流轉很是重要。（使用如下規則能夠更容易：保持細粒度）

長段時間 Code Review 延遲可能會下降生產力和士氣。聽到你在 3 天前就已經分提交給審查的 PR 的 feedback 是使人不快的。哦耶。我在這作什麼？來回切換開發環境和代碼上下文。要糾正這個問題，您須要提醒您的團隊，衡量進度須要從團隊的視角出發而非我的。讓您的團隊關注代碼審查延遲，並在團隊中變得更好。

若是您但願減小本身的審覈延遲，我建議遵循如下規則：在編寫任何新代碼之首先 Review 代碼。

做爲解決延遲的策略，請嘗試結對作 Code Review。搞一個配對站或啓動一個屏幕共享來討論 Code Review。一塊兒尋求解決方案並將代碼置於批准狀態。

8. 保持細粒度

你在 Code Review 上收到的反饋質量將與 Pull Request 的大小成反比。

爲了保持反饋的尖銳和建設性，最好知道較小的 Pull 請求使讀者更容易。

若是你保持 PR 很小（並避免Teeth），你須要有一個不一樣的場所來進行更大緯度的對話。 這個單一的 Pull Request 如何適應本週或本月的工做？咱們要去哪裏，這個 Pull Request 如何讓咱們在那裏？白板和臨時對話很是適合這些類型的討論。對於較小的 Pull 請求，可能很難記住它所寫的上下文。

「小」將因語言和團隊而異。 對於我本身，我試圖讓 Pull Requests 總共少於 300 行。

結語

但願這 8 個技巧能夠幫助您和您的團隊更好的進行 Code Review。經過改進您的 Code Review 流程，你將得到更好的代碼質量，更快樂的團隊成員，並有但願創造出更好的業務。

關於Fundebug

Fundebug專一於JavaScript、微信小程序、微信小遊戲、支付寶小程序、React Native、Node.js和Java線上應用實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了10億+錯誤事件，付費客戶有Google、360、金山軟件、百姓網等衆多品牌企業。歡迎你們免費試用！