閱讀和代碼評審是每個工程師在日常工作中都要做的事情，然而一個標準的code review流程，實際上很難落地，它要求每次代碼變更在部署到生產(chǎn)環(huán)境前，甚至是在提交合并前，都需要被另外一個小組成員進行正式的評審。在LinkedIn公司，自從2011年起code review成為了開發(fā)流程中法定、強制的一部分，也意味著它成為代碼質(zhì)量保證和知識分享中必不可少的一部分，目標是讓團隊成員能夠迅速提升自己的技能水平

實施公司級的code review最大的一個收益是提升了研發(fā)流程的標準化，在LinkedIn公司每個團隊使用相同的工具或者流程進行代碼評審，意味著任何一個人對其他團隊的項目可以提供評審幫助或者貢獻代碼，這消除了諸如“我可以修復(fù)代碼中的錯誤，但如何構(gòu)建代碼并提交修復(fù)程序？”這樣的問題，這反過來有助于增加工程組織中不同團隊之間的協(xié)作

我們在將代碼評審變成一項法定流程的過程中，為公司建立了良好健康的反饋文化，工程師在他們領(lǐng)域中樂于提出或者接收反饋，而不只是埋頭苦干寫代碼。實際上，高質(zhì)量的代碼審查經(jīng)驗是在公司晉升參考中是舉足輕重的，因為那是工程技能最直接的客觀證據(jù)

通過過去很長一段時間實踐，我們總結(jié)出了在代碼評審中的一些最佳實踐和技巧，如下面所示，通過問題的形式呈現(xiàn)，盡量讓審查雙方都能從中獲得最大的價值

我真的明白代碼變更的目的是什么嗎？

為了加快高質(zhì)量的code review流程和有效提高團隊技能，每次變更提交的代碼文件中應(yīng)該包括變更概要，簡要說明背后的需求或者動機是什么，而不是需要從代碼更改本身反向推斷。實際上，為提交代碼寫說明文檔是重新梳理的過程，從中你可能會發(fā)現(xiàn)自己把需求實現(xiàn)搞復(fù)雜了，應(yīng)該再簡化下，于是就回頭改代碼，從而改善已有代碼的設(shè)計，甚至培養(yǎng)出做事之前先進行推演等等好習(xí)慣

我提出的建議是積極反饋嗎？

整潔的代碼和高度測試覆蓋率被視為理所當(dāng)然的，然而有些code review過于關(guān)注代碼問題，側(cè)重點變成代碼怎么修改才能變得更好，這非常不好，大部分人需要積極的反饋才能得到鼓舞和提高積極性，工程師也不例外，我們不能忽視正面贊賞的價值。當(dāng)審查員發(fā)現(xiàn)代碼中好的設(shè)計時，應(yīng)該提出來并給予肯定，這種積極的反饋往往具有傳染性，它能讓整個團隊變得更加有活力

我的代碼評審評論表達清楚了嗎？

和所有的代碼提交一樣，任何積極或者消極的反饋都不應(yīng)該空談，應(yīng)該有針對性的解釋，如果覺得代碼提交者收到反饋后可能一頭霧水，可以進行過度解釋而不是簡潔，不然會產(chǎn)生更多的問題，并需要更多來回溝通。當(dāng)然，注釋也可以非常簡潔，比如”消除了重復(fù)代碼”、“增加了測試覆蓋率”，這種類型的解釋有助于讓團隊的價值觀得以明確

我是否需要感謝提交者的努力？

某些代碼質(zhì)量不高，需要返工重新編寫，在這種情況下，重要的是仍然承認他為之付出的努力，他之前可能只是對業(yè)務(wù)熟悉程度不夠，最佳方式是提供高質(zhì)量的code review反饋和正確的解釋，比如提出“謝謝你，每次代碼提交中始終有好的設(shè)計”之類的話語，而不是幫他寫代碼，從長遠來看，這其實是在一定程度上復(fù)制你的生產(chǎn)力

我們可以從代碼評審中獲益嗎？

這個問題可以讓我們非常強有力并且粗暴地評估code review是否有必要。在下班前，工程師應(yīng)該像對待一個有幫助性的開發(fā)工具一樣正視代碼評審結(jié)果，優(yōu)先級應(yīng)該比其他工作還要高，如果認為沒有作用，就將其刪除。沒有意義的code review評論的典型示例是與代碼格式相關(guān)的，那些應(yīng)該由自動化工具并且是在編寫過程中驗證，而不是最后由工程師來完成

“測試完成”部分是否足夠徹底？

code review中，不但要審查提交者的代碼，還要關(guān)注做過的測試，除了一些單元測試，還有一些可能是手動的測試。提交者最好列出所有測試過的案例，這樣可以讓審查者做出更多的測試建議，從而提高質(zhì)量

在review反饋中，我是否太迂腐了？

一些code review在重要的問題上提出了相當(dāng)多的修復(fù)意見，而不是強有力的建議，也就是說過于關(guān)注細節(jié)，過于炫技，從而拖慢了整個進度，甚至?xí)斐呻p方的隔陔。建立一個清晰的、有明確目標、積極的、有吸引力的code review流程是避免上述問題的好方法

總結(jié)一下，一個標準的code review流程能夠提升代碼質(zhì)量、團隊技能和知識互通。當(dāng)團隊中每個工程師都意識到，其他人會閱讀我的代碼，同時我需要認真對待評審結(jié)果，下次代碼編寫要參考評論然后制作得更好，從而提高工作質(zhì)量，這是增長和改善的關(guān)鍵

文章來源：www.liangsonghua.me

作者介紹：京東資深工程師-梁松華，在穩(wěn)定性保障、敏捷開發(fā)、JAVA高級、微服務(wù)架構(gòu)方面有深入的理解