程序員必看：如何充分利用代碼審查提高你的代碼質量？

咱們做爲軟件工程師，工做上保持代碼審查的習慣是很重要的。 而審查其實就像編寫代碼同樣，必須不斷練習並提供反饋，這一點相當重要。 如下是VTS工程師制訂的代碼審查目標及一些改善建議。

代碼審查的兩個主要目標是：

1

提升代碼質量

審查能夠經過如下方式提升代碼質量：

• 查找並修復代碼漏洞—咱們須要高質量的代碼，特別是在應用程序已經面向大衆的狀況下。
• 驗證如今的程序是否可以配合將來的更新。
• 找到bug和極端狀況—並不是全部的bug或極端狀況都能被發現，可是經過審查能夠減小它們。並且掃除過程當中的專一閱讀是很好的學習機會。
• 遵循良好的commit規範。

2

共享技術和領域知識

---

代碼審查的交互過程讓編程人員和審查人員能夠相互學習分享，共同進步。

---

---

下面的實踐能夠幫助您在進行代碼審查時實現以上目標。

1

尋找本身及團隊對代碼審查的角度

試問本身—爲何您(或您的團隊)要求對代碼進行審覈? 您當即會以您所屬領域的技術知識來回答，而思考出發點的不一樣可使您以不一樣的角度審查代碼，一樣地，您團隊的成員也會帶着本身的角度去進行代碼審查。所以您能夠選擇本身一我的以單一的角度審查全部代碼，或者與團隊協做，以不一樣角度去審查代碼。

_團隊一旦熟悉了不一樣隊員的審查角度，我的就更容易知道如何爲代碼作出貢獻。_您能夠改善新架構的設計嗎？您能夠幫助重構某些代碼嗎？您是否能夠從您自身的經驗中發現到一些未解決的edge cases？這些問題均可以幫助您找出本身專業的領域。

即使代碼問題成功解決了，你仍然能夠從您的角度考慮如何解決問題。您的解決方案是否不一樣，或者更好？您的解決方案可能會有所不一樣，由於您：

• 具備不一樣的技能和/或經驗水平。
• 在要解決的問題上沒有刻板認知。
• 爲問題帶來不一樣的領域知識（例如在數據質量與性能方面）。
• 對代碼庫有不一樣程度的瞭解和經驗。

不一樣的解決方案並不必定意味着一個要比另外一種更好，這僅僅是解決問題的另外一種方式。若是您以爲其餘解決方案更好，請務必向團隊說明緣由。這些差別可能會引發有關開發者的疑問，有機會所以而引起建設性對話。

上述作法的結果是—您能夠提供原做者沒有或可能沒有考慮過的觀點。

2

不要批准您不瞭解的項目

這適用於全部級別的工程師。若是您須要更多信息，請詢問原做者。 若是原做者但願您爲他們審查代碼，那麼他們將花時間向您解釋代碼。

您在開口請求代碼審查時不該感到壓力，您也不該由於不瞭解內容因此主動發問而感到慚愧。 對於每一個工做場所而言，提升團隊的心理安全感相當重要，這樣每一個人均可以自由地分享想法和提出問題。

還有一種多是，若是您不理解內容，那麼可能做者本身其實也不理解內容。 他也許是從Stack Overflow複製/粘貼的；也許他們放棄了代碼，不記得本身想作什麼；也許太複雜了。因此在代碼合併及修改前請確保理解原做者的想表達的意思。

上述作法的結果是—令咱們找到更簡單的解決方案，更易於維護和開發。

3

在本地檢驗運行

有時候您須要查看代碼在整個系統中的使用狀況。 在這種狀況下，您須要在您的編輯器中瀏覽文件並在本地檢驗運行。 提出相似的問題：

• 該方法是否正確使用？
• 這是否遵循與其餘類別相同的設計？
• 是否還有更多重構的機會，它們是否能夠與此代碼合併？
• 測試足夠全面嗎？
• 這如何與系統的其他部分集成？

上述問題的回答是—_能_幫助您更好地理解代碼與軟件總體相適應的關係。甚至能夠引導您找到進一步的機會來重構或修復原代碼。

4

避免無建設性意見的批評

若是代碼合併上確實存在缺陷，那麼指出錯誤是很重要的。 但一樣重要的是，在能改進和不破壞原結構的前提下，提出有關修復或避免該缺陷的建議。

您能夠先是解釋沒法正常工做的內容，而後提出更好的解決方案來作到這一點。您還能夠透過一些連接文章或使用stack overflow來爲其找出答案。

誠然，有時您可能知道有一種改進方法，可是不肯定該怎麼作。若是面對這種狀況，請務必爲原做者留下一個開放式問題，以便您能夠就如何解決此問題進行對話。

這種作法的結果是—原做者理解爲何提出批評以及能夠採起什麼解決方案。

5

尋找讚揚別人的機會

咱們都須要正向的反饋，以加強咱們的信心。 請求其餘人修改代碼是一項艱鉅的任務。 咱們須要找到方法，以不斷鼓勵彼此盡力而爲。 您知道原做者正在努力學習更強的代碼重構技術？ 若是您看到他們的努力，請不要吝嗇並告訴他們現階段取得的成果。 代碼如今更具可讀性了嗎？ 爲此讚美他們—這些讚美對團隊中的全部人都管用。

另外一個好處是，這些對他人的讚美代表您認真對待了這次審覈。 有時咱們沒有任何反饋，只是批准修改。 做者怎麼知道您真的看過它？ 給予代碼中某特定部分很高的評價是一種方法。

這種作法的結果是—_使原做者感到鼓舞，他們繼續爲該代碼作出貢獻，並繼續學習來提升本身的技能。_

6

保持緊密的反饋

在編寫代碼的整個過程當中，反饋很重要。 選擇適當的時機，在代碼合併以前尋求他人的反饋。 在項目初期，一般沒必要詢問與代碼有關的問題。 您能夠查看是否還有未考慮過的想法，或者目前境況是否就是繼續努力的最佳途徑。 儘早與您的隊友或具備領域/背景知識的人交談。

在收到反饋後，請務必快速回應每個觀點。 繼續回頭去處理代碼合拼很重要，只有這樣代碼纔不會被放棄。 它還將幫助您不用過於頻繁地進行上下文切換修改。

您還應該平衡異步和同步對話。 有時，面對面交談並確保各方之間的理解會更快。那麼若是面對異步交流，就請務必以書面形式記錄下來。

上述作法的結果是—更快地完成您的代碼合拼。若是剛好您要處理包含大量合併的大型代碼庫，那麼這一點尤爲重要。

7

創建有關commits的筆記

這個簡單的細節是值得作的，筆記做爲代碼檢查實踐的一部分，是相當重要的。爲了幫助代碼審查人的閱讀，做者須要保持乾淨且內容豐富的commits筆記。良好的commits筆記能夠幫助開發者得到最有用的反饋。

良好的commits筆記表明commits是垂直而不是水平分解的。這也意味着每次commits後都能經過全部測試，而且不會破壞主分支。良好的commits筆記也表明修改後的代碼可以融入主架構。透過commits筆記，這使得審查代碼的人能夠知道開發者的想法和決策。良好的commits筆記還留下了您進行修改的詳細緣由。簡單來講，commits筆記能夠記錄您在代碼的修改，能夠充當應用程序的文檔。最後，良好的commits筆記應該是獨立的，這意味着它們自身的存在就是有價值的，而且不須要審閱者查看其餘筆記就能夠理解它們。

做爲審閱者，您也須要尋找機會來作出好的commits筆記。

上述實踐的結果是—能生成一個信息全面且豐富的代碼庫，這些commits筆記能幫助使您的應用程序可持續發展。另外一個積極的結果是，它使代碼審查更加容易。

🔗原文連接：

https://buildingvts.com/how-t...

以上信息來源於網絡，由「京東智聯雲開發者」公衆號編輯整理，

不表明京東智聯雲立場

閱讀原文