[譯]LinkedIn的高效代碼審查技巧

本文翻譯自https://thenewstack.io/linkedin-code-review/

image.png

LinkedIn最近通過了進行一百萬次代碼審查的里程碑。社交網(wǎng)絡服務工具的??負責人在此過程中分享了一些經(jīng)驗教訓。

閱讀和審查代碼是每個工程師每天都要做的事情。 然而,正式的代碼審查流程有點不同 - 它要求在代碼投入生產(chǎn)之前,每個代碼更改都要由另一個團隊成員進行正式審核。在LinkedIn,自2011年以來,代碼審查一直是我們開發(fā)過程的必要組成部分。我們要求代碼審查的目標是盡可能順利地擴展我們快速發(fā)展的工程團隊。使用有意義的有用注釋進行良好的代碼審查可以幫助提升整個工程組織的水平。在LinkedIn,這些審查已成為質量保證和知識共享的重要組成部分。擁抱代碼審查已經(jīng)在幾個關鍵方面改變了我們的整個工程文化。

實施公司范圍的代碼審查的最大好處之一是我們的開發(fā)工作流程中的標準化程度提高了。LinkedIn的每個團隊都使用相同的工具和流程進行代碼審查,這意味著任何人都可以幫助審核或為其他團隊的項目貢獻代碼。這消除了諸如“我可以修復代碼中的錯誤,但我將如何構建代碼并提交修復程序?”這樣的問題,反過來,這有助于增加工程組織中不同團隊之間的協(xié)作。

通過使代碼審查成為強制性流程,我們還幫助培養(yǎng)了公司健康的反饋文化:工程師愿意在所有工作領域提供和接收反饋,而不僅僅是編碼,因為它已成為工作的常規(guī)組成部分。我們的工程師不會將代碼審查視為批評或否定,而是將提供和接收代碼審查作為專業(yè)發(fā)展的機會。事實上,高質量的代碼審查是LinkedIn推廣過程的重要組成部分,因為它們提供了工程技能的客觀證據(jù)。

多年來,我們已經(jīng)磨練了幾個最佳實踐和技巧,以便提供真正優(yōu)秀的審查。以下是一些問題形式的指南,我們建議您幫助確保審核人員和審核人員從代碼審核中獲得最大價值。


我理解“為什么”?

為了促進最佳審核并幫助您的團隊擴展,每個代碼更改提交都應包含一個設計概述,簡要說明更改背后的動機。當需要從代碼更改本身推斷出基本原理時,很難提供高質量的代碼審查。在提交代碼審查之前,詢問并期望提交者解釋他們的動機是公平的。這也鼓勵提交者在提交消息中進行解釋,從而提高代碼文檔的質量。


我給予正面反饋嗎?

在一個充滿聰明人的組織中,干凈的代碼和整潔的測試覆蓋率可以被視為理所當然。因此,代碼審查反饋往往只關注代碼中發(fā)現(xiàn)的問題。這是非常不幸的,因為大多數(shù)人需要積極的反饋才能感受到參與和積極性 - 工程師也不例外。當審閱者在代碼中看到好東西時,他們應該調用它并給出積極的反饋。這有助于改善團隊動態(tài),而且這種積極反饋往往具有傳染性。與所有代碼審查評論一樣(下面有更多內(nèi)容),任何積極的反饋都應該具體,解釋為什么特定的代碼寫得很好。


我的代碼審查評論解釋得很好嗎?

無論反饋是正面的還是負面的,任何代碼審查評論都應該是不言自明的。對于收到解釋不佳的代碼審查意見的工程師來說,審閱者看起來顯而易見的事情可能并不明確。如果有疑問,最好是更多的解釋,而不是提供簡潔的反饋,從而產(chǎn)生更多的問題,并需要更多的來回溝通。解釋可以簡單到“減少重復”,“改善覆蓋范圍”或“使代碼更容易測試”。除了使評論者的評論更加清晰之外,這些類型的解釋還有助于強化團隊渴望滿足的設計原則。


我是否欣賞提交者的努力?

無論結果如何,總是需要努力工作 - 這將培養(yǎng)強大,積極進取的團隊。某些代碼更改不是最高質量的,需要重新編寫。在這些情況下,即使代碼需要重新編寫,仍然承認作者為更改付出的努力是很重要的。表達贊賞的最佳方式是通過提供高質量的反饋和正確的解釋,努力為您的代碼審查,確認好的想法(每個代碼提交中始終有好的東西!),并使用“謝謝”。


這篇審查評論對我有用嗎?

提出這個問題是驗證代碼審查評論是否必要的簡單而有效的方法。在一天結束時,工程師應該將代碼審查視為有用的開發(fā)工具,而不是不重要的繁忙工作的來源。如果您認為特定審查評論對您沒有用,請將其刪除。無用的代碼審查注釋的典型示例是與代碼格式相關的注釋。代碼樣式和格式應該由自動化工具驗證,而不是工程師。


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

在LinkedIn,每個代碼更改提交都有一個強制性的“測試完成”部分,需要填寫。在開源世界中,使用GitHub作為示例,工程師可以在拉取請求描述中提交“測試完成”信息?!巴瓿蓽y試”應該取決于變化的嚴重程度和當前的測試覆蓋水平。如果更改包含新的或更改的條件復雜性,那么期望它在單元測試中被涵蓋是公平的。如果集成測試覆蓋率不足,某些更改可能需要運行手動測試。在這些情況下,“測試完成”應包括有關測試場景和輸出的信息。當更改改變程序的輸出時,將新輸出包含在“測試完成”部分中非常有用。


我的審查評論中是否太迂腐了?

一些代碼審查有很多評論,重要的問題 - 真正需要修復的問題 - 在不太重要的建議中丟失。對特定團隊的詳細信息過于繁重的審查可能會減慢審核周期并導致審核人員和審核人員之間產(chǎn)生摩擦。明確的審核期望,示例評論以及積極,有吸引力的審核文化是避免冗長,耗費精力的審核周期的好方法。


總之,擁有正式的代碼審查流程有助于提高代碼質量,團隊學習和知識共享。當團隊中的每個工程師都意識到兩件重要的事情時,工作質量會提高:別人會讀我的代碼,所以最好是好的,我將不得不解決我收到的任何評論意見,所以我應該盡量讓我的代碼第一次好,以便以后節(jié)省自己的努力。當代碼審查成為日常習慣時,團隊會每天實施給予和接收反饋。這是增長和改善的關鍵。
在LinkedIn,我們從過去的一百萬次代碼評審中學到了很多東西,我們希望從下一個百萬代碼中學到更多。代碼審查所付出的努力越多,團隊在提供出色的代碼審查方面就越好,簽入的代碼質量就越高,產(chǎn)品的質量就越高。高質量的代碼審查具有傳染性!

最后編輯于
?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容