本文翻譯自https://thenewstack.io/linkedin-code-review/
LinkedIn最近通過(guò)了進(jìn)行一百萬(wàn)次代碼審查的里程碑。社交網(wǎng)絡(luò)服務(wù)工具的??負(fù)責(zé)人在此過(guò)程中分享了一些經(jīng)驗(yàn)教訓(xùn)。
閱讀和審查代碼是每個(gè)工程師每天都要做的事情。 然而，正式的代碼審查流程有點(diǎn)不同 - 它要求在代碼投入生產(chǎn)之前，每個(gè)代碼更改都要由另一個(gè)團(tuán)隊(duì)成員進(jìn)行正式審核。在LinkedIn，自2011年以來(lái)，代碼審查一直是我們開(kāi)發(fā)過(guò)程的必要組成部分。我們要求代碼審查的目標(biāo)是盡可能順利地?cái)U(kuò)展我們快速發(fā)展的工程團(tuán)隊(duì)。使用有意義的有用注釋進(jìn)行良好的代碼審查可以幫助提升整個(gè)工程組織的水平。在LinkedIn，這些審查已成為質(zhì)量保證和知識(shí)共享的重要組成部分。擁抱代碼審查已經(jīng)在幾個(gè)關(guān)鍵方面改變了我們的整個(gè)工程文化。
實(shí)施公司范圍的代碼審查的最大好處之一是我們的開(kāi)發(fā)工作流程中的標(biāo)準(zhǔn)化程度提高了。LinkedIn的每個(gè)團(tuán)隊(duì)都使用相同的工具和流程進(jìn)行代碼審查，這意味著任何人都可以幫助審核或?yàn)槠渌麍F(tuán)隊(duì)的項(xiàng)目貢獻(xiàn)代碼。這消除了諸如“我可以修復(fù)代碼中的錯(cuò)誤，但我將如何構(gòu)建代碼并提交修復(fù)程序？”這樣的問(wèn)題，反過(guò)來(lái)，這有助于增加工程組織中不同團(tuán)隊(duì)之間的協(xié)作。
通過(guò)使代碼審查成為強(qiáng)制性流程，我們還幫助培養(yǎng)了公司健康的反饋文化：工程師愿意在所有工作領(lǐng)域提供和接收反饋，而不僅僅是編碼，因?yàn)樗殉蔀楣ぷ鞯某Ｒ?guī)組成部分。我們的工程師不會(huì)將代碼審查視為批評(píng)或否定，而是將提供和接收代碼審查作為專業(yè)發(fā)展的機(jī)會(huì)。事實(shí)上，高質(zhì)量的代碼審查是LinkedIn推廣過(guò)程的重要組成部分，因?yàn)樗鼈兲峁┝斯こ碳寄艿目陀^證據(jù)。
多年來(lái)，我們已經(jīng)磨練了幾個(gè)最佳實(shí)踐和技巧，以便提供真正優(yōu)秀的審查。以下是一些問(wèn)題形式的指南，我們建議您幫助確保審核人員和審核人員從代碼審核中獲得最大價(jià)值。
我理解“為什么”？
為了促進(jìn)最佳審核并幫助您的團(tuán)隊(duì)擴(kuò)展，每個(gè)代碼更改提交都應(yīng)包含一個(gè)設(shè)計(jì)概述，簡(jiǎn)要說(shuō)明更改背后的動(dòng)機(jī)。當(dāng)需要從代碼更改本身推斷出基本原理時(shí)，很難提供高質(zhì)量的代碼審查。在提交代碼審查之前，詢問(wèn)并期望提交者解釋他們的動(dòng)機(jī)是公平的。這也鼓勵(lì)提交者在提交消息中進(jìn)行解釋，從而提高代碼文檔的質(zhì)量。
我給予正面反饋嗎？
在一個(gè)充滿聰明人的組織中，干凈的代碼和整潔的測(cè)試覆蓋率可以被視為理所當(dāng)然。因此，代碼審查反饋往往只關(guān)注代碼中發(fā)現(xiàn)的問(wèn)題。這是非常不幸的，因?yàn)榇蠖鄶?shù)人需要積極的反饋才能感受到參與和積極性 - 工程師也不例外。當(dāng)審閱者在代碼中看到好東西時(shí)，他們應(yīng)該調(diào)用它并給出積極的反饋。這有助于改善團(tuán)隊(duì)動(dòng)態(tài)，而且這種積極反饋往往具有傳染性。與所有代碼審查評(píng)論一樣（下面有更多內(nèi)容），任何積極的反饋都應(yīng)該具體，解釋為什么特定的代碼寫得很好。
我的代碼審查評(píng)論解釋得很好嗎？
無(wú)論反饋是正面的還是負(fù)面的，任何代碼審查評(píng)論都應(yīng)該是不言自明的。對(duì)于收到解釋不佳的代碼審查意見(jiàn)的工程師來(lái)說(shuō)，審閱者看起來(lái)顯而易見(jiàn)的事情可能并不明確。如果有疑問(wèn)，最好是更多的解釋，而不是提供簡(jiǎn)潔的反饋，從而產(chǎn)生更多的問(wèn)題，并需要更多的來(lái)回溝通。解釋可以簡(jiǎn)單到“減少重復(fù)”，“改善覆蓋范圍”或“使代碼更容易測(cè)試”。除了使評(píng)論者的評(píng)論更加清晰之外，這些類型的解釋還有助于強(qiáng)化團(tuán)隊(duì)渴望滿足的設(shè)計(jì)原則。
我是否欣賞提交者的努力？
無(wú)論結(jié)果如何，總是需要努力工作 - 這將培養(yǎng)強(qiáng)大，積極進(jìn)取的團(tuán)隊(duì)。某些代碼更改不是最高質(zhì)量的，需要重新編寫。在這些情況下，即使代碼需要重新編寫，仍然承認(rèn)作者為更改付出的努力是很重要的。表達(dá)贊賞的最佳方式是通過(guò)提供高質(zhì)量的反饋和正確的解釋，努力為您的代碼審查，確認(rèn)好的想法（每個(gè)代碼提交中始終有好的東西?。⑹褂谩爸x謝”。
這篇審查評(píng)論對(duì)我有用嗎？
提出這個(gè)問(wèn)題是驗(yàn)證代碼審查評(píng)論是否必要的簡(jiǎn)單而有效的方法。在一天結(jié)束時(shí)，工程師應(yīng)該將代碼審查視為有用的開(kāi)發(fā)工具，而不是不重要的繁忙工作的來(lái)源。如果您認(rèn)為特定審查評(píng)論對(duì)您沒(méi)有用，請(qǐng)將其刪除。無(wú)用的代碼審查注釋的典型示例是與代碼格式相關(guān)的注釋。代碼樣式和格式應(yīng)該由自動(dòng)化工具驗(yàn)證，而不是工程師。
“測(cè)試完成”部分是否足夠徹底？
在LinkedIn，每個(gè)代碼更改提交都有一個(gè)強(qiáng)制性的“測(cè)試完成”部分，需要填寫。在開(kāi)源世界中，使用GitHub作為示例，工程師可以在拉取請(qǐng)求描述中提交“測(cè)試完成”信息?！巴瓿蓽y(cè)試”應(yīng)該取決于變化的嚴(yán)重程度和當(dāng)前的測(cè)試覆蓋水平。如果更改包含新的或更改的條件復(fù)雜性，那么期望它在單元測(cè)試中被涵蓋是公平的。如果集成測(cè)試覆蓋率不足，某些更改可能需要運(yùn)行手動(dòng)測(cè)試。在這些情況下，“測(cè)試完成”應(yīng)包括有關(guān)測(cè)試場(chǎng)景和輸出的信息。當(dāng)更改改變程序的輸出時(shí)，將新輸出包含在“測(cè)試完成”部分中非常有用。
我的審查評(píng)論中是否太迂腐了？
一些代碼審查有很多評(píng)論，重要的問(wèn)題 - 真正需要修復(fù)的問(wèn)題 - 在不太重要的建議中丟失。對(duì)特定團(tuán)隊(duì)的詳細(xì)信息過(guò)于繁重的審查可能會(huì)減慢審核周期并導(dǎo)致審核人員和審核人員之間產(chǎn)生摩擦。明確的審核期望，示例評(píng)論以及積極，有吸引力的審核文化是避免冗長(zhǎng)，耗費(fèi)精力的審核周期的好方法。
總之，擁有正式的代碼審查流程有助于提高代碼質(zhì)量，團(tuán)隊(duì)學(xué)習(xí)和知識(shí)共享。當(dāng)團(tuán)隊(duì)中的每個(gè)工程師都意識(shí)到兩件重要的事情時(shí)，工作質(zhì)量會(huì)提高：別人會(huì)讀我的代碼，所以最好是好的，我將不得不解決我收到的任何評(píng)論意見(jiàn)，所以我應(yīng)該盡量讓我的代碼第一次好，以便以后節(jié)省自己的努力。當(dāng)代碼審查成為日常習(xí)慣時(shí)，團(tuán)隊(duì)會(huì)每天實(shí)施給予和接收反饋。這是增長(zhǎng)和改善的關(guān)鍵。
在LinkedIn，我們從過(guò)去的一百萬(wàn)次代碼評(píng)審中學(xué)到了很多東西，我們希望從下一個(gè)百萬(wàn)代碼中學(xué)到更多。代碼審查所付出的努力越多，團(tuán)隊(duì)在提供出色的代碼審查方面就越好，簽入的代碼質(zhì)量就越高，產(chǎn)品的質(zhì)量就越高。高質(zhì)量的代碼審查具有傳染性！
