摘要: Code Review 能夠提升代碼質量。html
Fundebug經受權轉載,版權歸原做者全部。前端
原文地址:https://kellysutton.com/2018/10/08/8-tips-for-great-code-reviews.html
更多內容請見譯者 Blog:https://github.com/elevenbeans/elevenbeans.github.iogit
你在學校裏未曾學到的東西中有一件是:如何才作出優秀的 Code Review。你學到了算法、數據結構、編程語言基礎知識,但沒有人坐下來講:「下面介紹如何確保你如何(對同事)提出很棒的反饋(Code Review)」。github
Code Reviews 是開發出好軟件的關鍵過程。通過審覈的代碼每每質量較高、錯誤較少。一個良性的 Code Reviews 文化也提供了額外的好處:算法
在咱們深刻研究以前,爲這篇文章中的要點作一些假設是很重要的。 它們以下:編程
如今咱們已經制定了一些基本規則,讓咱們深刻研究。segmentfault
很好理解,你即將審覈的代碼中,有人花了時間、付出了心血。他們會但願本身的代碼寫的很棒。你的同事會表現出最好的意圖,沒有人願意發送蹩腳的代碼。數據結構
保持客觀是很是困難的。你須要始終確保批評代碼自己,並嘗試理解編寫代碼的上下文。儘量多地取消除區隔。而不是說:編程語言
你以一種使人困惑的方式寫了這個方法。ide
請嘗試從新改寫代碼自己以及從新理清對 Ta 的理解:
這個方法讓我有點困惑,咱們能爲這個變量找到一個更好的名字嗎?
這裏,咱們會解釋咱們做爲讀者對代碼的見解。這不是他們的行爲或意圖。這是關於咱們和咱們對代碼的解釋。
每一個 PR 都是它本身的艱難對話。嘗試與您的同事達成共識,共同努力實現更好的代碼。
若是您剛剛結識了同事,而且您對 PR 有重要反饋,請一塊兒瀏覽代碼。這將是一個與同事創建關係的好機會。與每位同事一塊兒作到這一點,直到這件事情讓你再也不感受尷尬。
若是計算機能夠決定並執行規則,請讓計算機執行此操做。無休止地爭論 Space 與 Tab 並不能充分利用時間、提升任何效率。相反,應該花時間對於規則達成一致意見。在低風險情景中,這有機會可讓你瞭解你的團隊在 「不認同但承諾」方面的表現。
語言和現代工具鏈不缺少執行規則(linting)和複用它們的方法。 在 Ruby 中,你有 Rubocop; 在 JavaScript 中,Jslint/eslint。 找到你的語言的 linter 並將其插入你項目的構建流程。
若是您發現缺乏現有的 linter,請本身編寫! 編寫本身的規則很是簡單。 在 Gusto 中,咱們使用自定義的 linter 規則來捕捉類的棄用或溫和地提醒人們遵照一些 Sidekiq 的最佳實踐。
將全部代碼審查職責一股腦全交給 Shirley 是很誘人的。
Shirley 是一個關於代碼的大師,她老是知道什麼是最好的。她知道系統的前因後果,並且她在公司工做的時間超過了團隊的集體任期。
然而,僅僅由於 Shirley 理解某些事情並不意味着她的團隊中的其餘人能夠理解。年輕的團隊成員可能會對指出 Shirley 的代碼評論的問題而猶豫不決。
我發現將評論分發給團隊的不一樣成員會產生更健康的團隊互動和更好的代碼。初級工程師在代碼審查中最強大的一句是「我發現這使人困惑。」這些就是使代碼更清晰,更簡單的機會。
請傳播這些評論。
在 Gusto,咱們使用 GitHub 來管理咱們的代碼項目。幾乎 GitHub 上的每一個<textarea>
都支持Markdown,這是一種在評論中添加 HTML 格式的簡單方法。
擁抱 Markdown 是讓事物變得可讀的好方法。GitHub 或您選擇的工具可能具備語法突出顯示,這對於刪除一些代碼片斷很是有用。使用內聯代碼的單反引號(`)或代碼塊的三重反引號(```)能夠更好地傳達想法。
熟悉 Markdown 語法,特別是在註釋中編寫代碼時。 這樣作有助於保持您的評論具體和專一。
代碼評論本質上是負面的事情。在我要將此代碼發佈到線上環境以前告訴我這個代碼有什麼問題,這是挺傷人的事兒。有人花時間在這上面,並指望你會指出它會如何變得更好。
所以,請至少留下一個積極的評論。讓它變得有意義和極具個性。若是有人終於掌握了他們一直在努力的掌握的事情,那麼就請你把它 Ta 出來。 它能夠像點個贊