敏捷開發之LinkedIn的高效代碼評審技巧

閱讀和代碼評審是每一個工程師在平常工做中都要作的事情，然而一個標準的code review流程，實際上很難落地，它要求每次代碼變動在部署到生產環境前，甚至是在提交合並前，都須要被另一個小組成員進行正式的評審。在LinkedIn公司，自從2011年起code review成爲了開發流程中法定、強制的一部分，也意味着它成爲代碼質量保證和知識分享中必不可少的一部分，目標是讓團隊成員可以迅速提高本身的技能水平

實施公司級的code review最大的一個收益是提高了研發流程的標準化，在LinkedIn公司每一個團隊使用相同的工具或者流程進行代碼評審，意味着任何一我的對其餘團隊的項目能夠提供評審幫助或者貢獻代碼，這消除了諸如「我能夠修復代碼中的錯誤，但如何構建代碼並提交修復程序？」這樣的問題，這反過來有助於增長工程組織中不一樣團隊之間的協做

咱們在將代碼評審變成一項法定流程的過程當中，爲公司創建了良好健康的反饋文化，工程師在他們領域中樂於提出或者接收反饋，而不僅是埋頭苦幹寫代碼。實際上，高質量的代碼審查經驗是在公司晉升參考中是舉足輕重的，由於那是工程技能最直接的客觀證據

經過過去很長一段時間實踐，咱們總結出了在代碼評審中的一些最佳實踐和技巧，以下面所示，經過問題的形式呈現，儘可能讓審查雙方都能從中得到最大的價值

我真的明白代碼變動的目的是什麼嗎？

爲了加快高質量的code review流程和有效提升團隊技能，每次變動提交的代碼文件中應該包括變動概要，簡要說明背後的需求或者動機是什麼，而不是須要從代碼更改自己反向推斷。實際上，爲提交代碼寫說明文檔是從新梳理的過程，從中你可能會發現本身把需求實現搞複雜了，應該再簡化下，因而就回頭改代碼，從而改善已有代碼的設計，甚至培養出作事以前先進行推演等等好習慣

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

整潔的代碼和高度測試覆蓋率被視爲理所固然的，然而有些code review過於關注代碼問題，側重點變成代碼怎麼修改才能變得更好，這很是很差，大部分人須要積極的反饋才能獲得鼓舞和提升積極性，工程師也不例外，咱們不能忽視正面讚揚的價值。當審查員發現代碼中好的設計時，應該提出來並給予確定，這種積極的反饋每每具備傳染性，它能讓整個團隊變得更加有活力

個人代碼評審評論表達清楚了嗎？

和全部的代碼提交同樣，任何積極或者消極的反饋都不該該空談，應該有針對性的解釋，若是以爲代碼提交者收到反饋後可能一頭霧水，能夠進行過分解釋而不是簡潔，否則會產生更多的問題，並須要更多來回溝通。固然，註釋也能夠很是簡潔，好比」消除了重複代碼」、「增長了測試覆蓋率」，這種類型的解釋有助於讓團隊的價值觀得以明確

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

某些代碼質量不高，須要返工從新編寫，在這種狀況下，重要的是仍然認可他爲之付出的努力，他以前可能只是對業務熟悉程度不夠，最佳方式是提供高質量的code review反饋和正確的解釋，好比提出「謝謝你，每次代碼提交中始終有好的設計」之類的話語，而不是幫他寫代碼，從長遠來看，這實際上是在必定程度上覆制你的生產力

咱們能夠從代碼評審中獲益嗎？

這個問題可讓咱們很是強有力而且粗暴地評估code review是否有必要。在下班前，工程師應該像對待一個有幫助性的開發工具同樣正視代碼評審結果，優先級應該比其餘工做還要高，若是認爲沒有做用，就將其刪除。沒有意義的code review評論的典型示例是與代碼格式相關的，那些應該由自動化工具而且是在編寫過程當中驗證，而不是最後由工程師來完成

「測試完成」部分是否足夠完全？

code review中，不但要審查提交者的代碼，還要關注作過的測試，除了一些單元測試，還有一些多是手動的測試。提交者最好列出全部測試過的案例，這樣可讓審查者作出更多的測試建議，從而提升質量

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

一些code review在重要的問題上提出了至關多的修復意見，而不是強有力的建議，也就是說過於關注細節，過於炫技，從而拖慢了整個進度，甚至會形成雙方的隔陔。創建一個清晰的、有明確目標、積極的、有吸引力的code review流程是避免上述問題的好方法

總結一下，一個標準的code review流程可以提高代碼質量、團隊技能和知識互通。當團隊中每一個工程師都意識到，其餘人會閱讀個人代碼，同時我須要認真對待評審結果，下次代碼編寫要參考評論而後製做得更好，從而提升工做質量，這是增加和改善的關鍵

文章來源：www.liangsonghua.me
做者介紹：京東資深工程師-梁鬆華，在穩定性保障、敏捷開發、JAVA高級、微服務架構方面有深刻的理解