不要忽視代碼審查的重要性

這是一篇譯文，以爲它很不錯就把它翻譯了一下。原文名爲 8 Tips for Great Code Reviews，這篇文章不論是對提高我的編程素養，仍是協調團隊間的合做都有必定的指導意義。

在學校裏沒有教給你的一項本領就是怎樣作一個好的代碼審查(CR)。你學習了算法、數據結構、編程語言的基礎知識，但沒有人會坐下來對你說:「下面是如何確保你能得到很好的反饋的方法。」

代碼審查是建立優秀應用的關鍵過程。通過審查的代碼每每質量更高，bug更少。健康的代碼審查文化也提供了額外的好處：限制了巴士因子，它是培訓新成員的一個很好的工具，代碼審查是分享知識的好方法。

在咱們深刻討論以前，有必要對這篇文章中的觀點限制一下適用環境。限制條件是：

• 你在一個信任的環境中工做，或者你和你的團隊正在努力提升你的信任。
• 你應該可以在非代碼場景中交付反饋，或者在團隊中交付反饋。
• 你的團隊但願生成更好的代碼，而且理解完美是一個動詞而不是形容詞。咱們明天可能會找到更好的作事方法，咱們須要保持開放的心態。
• 你的公司重視高質量的代碼，而且理解事情可能不會「交付」得那麼快。「交付」是用引號括起來的，由於不少時候沒有通過測試和審查的代碼可能根本沒法工做。

既然咱們已經指定了一些基本限制條件，那麼讓咱們開始吧。

1. 咱們終究仍是人

要知道有人會在你要檢查的代碼上花時間。他們但願它是偉大的。你的同事的行爲是出於好意的，沒有人想要發佈糟糕的代碼。

保持客觀很難。確保始終對代碼自己進行評論，並嘗試在上下文中理解所編寫的代碼。盡你所能的把偏見去掉，不要這樣說：「你用一種令人困惑的方式寫了這個方法。」，試着換一種說法，把事情說成是關於代碼自己和你對它的解釋：「這個方法讓我有點困惑。這個變量有沒有更好的名字?」

在這個例子中，咱們解釋咱們做爲讀者對代碼的感覺，這與自身的行爲或意圖無關。它是關於咱們和咱們對代碼的解釋。

每個拉請求（Pull Request）都是一個艱難的對話。試着與你的隊友達成共同的理解，並一塊兒朝着更好的代碼努力。

若是你只是瞭解一個團隊成員，而且你對拉請求（Pull Request）有關鍵的反饋，那麼一塊兒瀏覽代碼。這將是開始與同事創建關係的好機會。和每位同事這樣作，直到他們再也不感到尷尬。

2. 自動化

若是電腦能決定並執行一條規則，就讓電腦去作吧。在空格和製表符之間爭論並非對人類時間的有效利用,相反把時間花在就規則應該是什麼達成一致上。這些機會可讓你看到你的團隊，在低風險的狀況下如何處理「不一樣意和承諾」。

現代的編譯語言工具和語言能夠開啓語法檢測功能，並反覆使用它們。在Ruby中，有Rubocop；在JavaScript中，有eslint；在CSS中，有stylelint。找到你須要的語法檢測工具，並將其插入到構建工具中。

若是你發現現有的語法檢測工具動力不足，能夠嘗試寫你本身的！

3. 每一個人都是代碼審查者

將全部代碼審查責任都交給Shirley，咋一聽來是頗有誘惑力的。

雖然，在編寫代碼方面，Shirley是一個奇才，她老是知道什麼是最好的，她瞭解公司制度的前因後果，並且她在公司工做的時間比大家團隊的集體任期還要長；

然而，Shirley理解了這些事情，並不意味着她的團隊中的其餘人也都理解。年輕的團隊成員可能會猶豫是否要在Shirley的代碼評審中指出一些問題。

我發現將評審分發給團隊的不一樣成員會產生更健康的團隊動態和更好的代碼。一個初級工程師在代碼評審中最有力的一句話是：「我以爲這很混亂」。這些都是使代碼更清晰、更簡單的機會。

推廣這些評論。

4. 加強可讀性

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

擁抱Markdown是讓代碼變得更加可讀。GitHub或你選擇的開發工具可能有語法高亮顯示功能，這對於插入一些代碼片斷很是有用。對於內聯代碼使用單回勾()或者對於代碼塊使用 （``）能夠更好地交流思想。

熟悉標記語法，特別是在註釋中編寫代碼時。這樣作將有助於使你的評論更加具體和集中。

5. 至少留下一句積極的評論

代碼審查本質上是負面的。在把代碼發送以前，告訴代碼的做者這個代碼有什麼問題，這是基本。但有些人在這這個代碼上面花了時間，他們但願你能指出怎樣才能作得更好。

所以，至少留下一句正面的話。讓它有意義和個性化。若是瞭解到他們一直在努力的解決問題，那就大聲喊出來，這能夠簡單 👍 或 「Love this.」

在每一個代碼評審上留下一些積極的內容，能夠微妙地提醒咱們，咱們是在一塊兒的。若是咱們建立更好的代碼，咱們都會受益。

6. 提供替代方案

我經常嘗試着去提供一個可替代的實現方案。對那些只學習了一門語言或框架的人更應該如此。

當要注意表達的方式。若是表述不正確，可能會讓人以爲你傲慢或自私。「儘可能保持客觀，並討論你所提供的備選方案的利弊。」若是作得好，這將有助於擴展每一個人的技術知識。

7. 審查延遲

保持一個極快的代碼審查速度很是重要的。(實現這個規則很簡單：保持審查代碼足夠小。)

長時間的代碼審查延遲會扼殺生產力和士氣。如：「3天前，你被分配去審查一份xxx的任務」，這聽起來很刺耳。

若是你但願減小本身的審查延遲，我建議遵循如下規則：在編寫任何新代碼以前審查代碼。

做爲一種直接處理延遲的策略，嘗試在代碼評審上進行配對。啓動一個屏幕共享來瀏覽和討論評論。對解決方案進行配對，使代碼達到批准的狀態。

8. 對於發件人來講：保持內容儘可能小

你在代碼評審中收到的反饋質量將與拉請求(Pull Request)的大小成反比。

爲了最大限度地保持反饋的尖銳和建設性，要知道較小的請求會讓讀者更容易接受。

若是你的拉請求（Pull Requests）很小，怎麼辦？這時你須要有一個不一樣的地方來進行詳細的描述。如：這個單一的拉請求（Pull Request）如何適合本週或本月的工做？咱們要去哪裏，這個拉請求是如何讓咱們到達那裏的？這種對話類型的方式在表現效果方面是很好的，由於對於較小的Pull請求，你很難記住它的編寫上下文。

小 這個概念會因語言的不一樣和團隊的不一樣而不一樣。對於我本身來講，我試圖讓Pull請求總數少於300行。

結論

但願這8個技巧能幫助你和你的團隊有更好的代碼審查。經過改進代碼審查過程，你將擁有更好的代碼、更快樂的團隊成員，帶來更好的業務。