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

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

我們?cè)趯⒋a評(píng)審變成一項(xiàng)法定流程的過程中咳促，為公司建立了良好健康的反饋文化稚新，工程師在他們領(lǐng)域中樂于提出或者接收反饋，而不只是埋頭苦干寫代碼跪腹。實(shí)際上褂删，高質(zhì)量的代碼審查經(jīng)驗(yàn)是在公司晉升參考中是舉足輕重的，因?yàn)槟鞘枪こ碳寄茏钪苯拥目陀^證據(jù)

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

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

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

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

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

我的代碼評(píng)審評(píng)論表達(dá)清楚了嗎错洁？

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

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

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

我們可以從代碼評(píng)審中獲益嗎奔坟？

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

“測(cè)試完成”部分是否足夠徹底炕舵？

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

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

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

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

文章來(lái)源：www.liangsonghua.me

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