程式設計師必看：如何充分利用程式碼審查提升你的程式碼質量？

我們作為軟體工程師，工作上保持程式碼審查的習慣是很重要的。   而審查其實就像編寫程式碼一樣，必須不斷練習並提供反饋，這一點至關重要。   以下是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筆記能幫助使您的應用程式可持續發展。另一個積極的結果是，它使程式碼審查更加容易。

?原文連結：

以上資訊來源於網路，由“京東智聯雲開發者”公眾號編輯整理，

不代表京東智聯雲立場

閱讀原文