2. 為什么要code review

代碼審查（Code Review）是現(xiàn)代軟件開發(fā)團隊中非常重要的一環(huán)，因為它可以帶來以下幾個方面的好處：

1. 提高代碼質(zhì)量: 通過代碼審查，開發(fā)團隊可以及時發(fā)現(xiàn)和修復代碼中的問題，包括代碼中的錯誤、潛在的安全漏洞、缺陷和性能問題等，從而提高代碼的質(zhì)量。
2. 減少維護成本: 通過及時發(fā)現(xiàn)和修復問題，代碼審查可以降低后續(xù)維護成本，因為修復問題的成本通常比在后期修復更低。
3. 加強知識共享和團隊協(xié)作: 代碼審查可以幫助團隊成員了解項目中其他成員的工作，從而促進知識共享和團隊協(xié)作，提高團隊整體的開發(fā)能力。
4. 提高編碼規(guī)范和標準的遵守: 通過代碼審查，可以促進團隊成員遵守編碼規(guī)范和標準，統(tǒng)一團隊的代碼風格和代碼質(zhì)量要求，提高代碼可讀性和可維護性。
5. 促進開發(fā)者的技能提升和成長：代碼審查可以幫助開發(fā)者了解項目中的技術細節(jié)和最佳實踐，從而促進開發(fā)者的技能提升和成長。

總之，代碼審查可以幫助開發(fā)團隊提高代碼質(zhì)量和開發(fā)效率，降低維護成本，提高團隊協(xié)作和開發(fā)者技能，從而在軟件開發(fā)項目中發(fā)揮重要作用。

3.review哪些部分的內(nèi)容呢

Code Review整個流程中，比較重要的一個節(jié)點，是對代碼進行Review,然后指出代碼中可能存在的問題。具體主要關注哪些代碼問題，應該是每個團隊，在實踐中總結出適合自己的一套規(guī)范。這里大概說明一些通用的Code Review可能需要關注的內(nèi)容。

3.1 代碼結構

1. 代碼的組織結構：代碼應該按照一定的組織結構進行編寫，例如按照功能模塊進行組織、按照層次結構進行組織等等。在審查代碼結構時，應該關注代碼的組織結構是否清晰、是否符合設計原則等方面。
2. 模塊化和可重用性：代碼應該具有一定的模塊化和可重用性，以便于代碼的復用和維護。在審查代碼結構時，應該關注代碼是否具有可重用的模塊、是否具有良好的接口設計等方面。
3. 代碼的層次結構：代碼應該按照一定的層次結構進行編寫，例如分為界面層、業(yè)務邏輯層、數(shù)據(jù)訪問層等等。在審查代碼結構時，應該關注代碼的層次結構是否清晰、是否具有良好的模塊劃分等方面。

3.2 代碼邏輯

代碼邏輯Review主要 包括條件分支、循環(huán)結構、異常處理、錯誤處理等方面的實現(xiàn)是否合理。

1. 條件分支的檢查。 判斷條件是否覆蓋了所有可能的情況，是否有重復的判斷條件是否有不必要的嵌套。
2. 循環(huán)結構的檢查。 檢查循環(huán)是否能夠正常終止，是否存在死循環(huán)，是否有更簡潔的循環(huán)方式。
3. 異常處理的檢查。 是否對所有的錯誤進行正確的處理，是否提供合適的錯誤提示，是否能夠記錄錯誤日志等。

3.3 代碼的可讀性和可維護性

Review代碼時，需要關注代碼的可讀性和可維護性，包括代碼的命名、注釋、縮進、代碼段的長度、函數(shù)和方法的參數(shù)和返回值等方面。

1. 命名應該清晰，簡潔，準確。代碼中的變量、函數(shù)、類等命名應該具有清晰、簡潔、準確的特點。而不是簡單的字母或數(shù)字，且應該使用一致的命名方式，避免混淆。
2. 注釋應該清晰、準確地描述代碼的含義和作用。不應該重復代碼，也不應該存在無用的注釋。注釋應該保持最新狀態(tài)，以便后續(xù)維護。
3. 代碼段的長度合適。：通常情況下，代碼段的長度應該保持在一個比較合理的范圍內(nèi)，以保證代碼的可讀性。一些通用的建議是，每個函數(shù)或方法的長度應該控制在 100 行以內(nèi)。
4. 函數(shù)和方法的參數(shù)和返回值規(guī)范。 函數(shù)和方法的參數(shù)應該盡量少，入?yún)⒑统鰠⑤^多的情況下，可以考慮使用DTO來封裝。函數(shù)和方法的返回值應該盡可能明確，避免使用不必要的返回值或無意義的返回值。
5. 避免使用魔法數(shù)字或魔法字符串。

3.4 代碼的可靠性

1. 入?yún)⒑戏ㄐ詸z查。 是否對輸入?yún)?shù)進行了合法性檢查，避免出現(xiàn)意外的輸入錯誤。
2. 單元測試檢查。 是否進行了足夠的單元測試，并且能夠覆蓋各種邊界情況。

3.5 代碼的可測試性

1. 可測試檢查。 代碼是否容易編寫測試用例，測試用例是否易于理解和維護。
2. 單元覆蓋率檢查。 測試覆蓋率是否足夠，是否存在測試漏洞或者未考慮到的場景。

4. 制定cr的規(guī)則和流程是什么呢

1. 確定團隊的目標和需求

2. 確定code review的規(guī)則和流程

   • code review的時間安排，確定審查時機，以及時間安排
   • 確定每次審查的代碼量
   • 確定審查的內(nèi)容: 定義一份可用的checklist，確保審查者可以根據(jù)標準和指導進行 review。
   • 確定用于進行 code review 的工具和環(huán)境
   • 確定審查后需要進行修改的代碼如何重新提交，如何跟蹤意見的處理過程。

3. 開始實施

4. 收集和分析數(shù)據(jù)

   • 收集數(shù)據(jù)

     • 收集問題類型和解決方式的數(shù)據(jù)，例如代碼問題的類型、解決方式、處理時間等

       1. 記錄代碼問題，如代碼可讀性等內(nèi)容
       2. 記錄問題的處理時間
       3. 對問題進行分類

     • 收集code review的時間安排/代碼量

       1. 收集每次code review的代碼量
       2. 收集開始code review的時機
       3. 每次code review耗時，包含開發(fā)和reviewer的耗時
       4. 對項目發(fā)布是否有影響

   • 數(shù)據(jù)分析

     • 根據(jù)數(shù)據(jù)記錄結果，獲取到code review經(jīng)常出現(xiàn)的問題

       1. 添加代碼靜態(tài)掃描規(guī)則，掃描出通用問題，減少code review問題
       2. 進行對應的分享，完成團隊內(nèi)的知識共享

     • 對code review的耗時進行分析，來改進流程

       1. 不同需求類型，每次code review的代碼量是否合適
       2. code review開始的時機是否合適
       3. code review是否對項目發(fā)布造成影響，在排期過程中，是否增加對code review的考慮
       4. 對reviewer的工作安排是否受到影響，有的話，如何解決

   • 效果分析

     1. 代碼質(zhì)量的提升: 通過比較一段時間下來，發(fā)現(xiàn)的問題數(shù)量是否減少

5. 規(guī)則和流程的優(yōu)化

5. 可以遵守的比較好的code review的準則

1. 每個提交的代碼必須經(jīng)過代碼審查，以確保代碼的質(zhì)量和可維護性。
2. 在代碼審查之前，開發(fā)人員應該對自己的代碼進行一次自審查，確保代碼沒有明顯的錯誤和問題。
3. 按照確定的規(guī)則進行審查：遵循指定的審查標準和流程，以確保一致性和準確性。
4. 代碼審查應該專注于發(fā)現(xiàn)代碼中的問題和缺陷，而不是對開發(fā)人員進行評價或指責。
5. 不要強制修改：審查人員應該將自己的建議視為建議而非命令，并與開發(fā)人員進行協(xié)商。
6. 在代碼審查中，開發(fā)人員應該積極參與討論，提出自己的觀點和想法，并接受他人的反饋和建議。
7. 代碼審查應該在合適的時間進行，以避免影響開發(fā)進度和項目交付時間。
8. 代碼審查結果應該被記錄下來，并及時修復和追蹤問題，確保問題得到解決和修復。

6. 如何讓code review跑起來

6.1 通過checklist來做code review

通過checkList來做code review似乎是一個比較好的方式，下面是開發(fā)者和reviewer的一個checkList的示例。

6.1.1 開發(fā)者的checklist

1. 需求評審需要邀請reviewer參加
2. 代碼被審查前，自己先review一遍
3. 需要提前和reviewer協(xié)調(diào)好代碼review的時間
4. 每次合并代碼前都需要通過代碼審查
5. 代碼有必要做單元測試的位置，已完成單元測試的覆蓋，單元測試已通過

6.1.2 reviewer的checkList

1. 需要review的代碼，需要參加需求評審/測試用例評審
2. 需要預先留出code review的時間，排期時確定
3. 代碼review根據(jù)審查標準執(zhí)行
   • 每次合并代碼是否通過代碼審查
   • 代碼結構是否符合規(guī)范
   • 代碼邏輯是否存在問題
   • 代碼是否具有一定的可讀性
   • 代碼單元測試用例是否覆蓋充分
4. 代碼review需要記錄問題類型，方便統(tǒng)計數(shù)據(jù)

6.2 限制 Code Review 時間

限制單次code review的時間，能夠避免待review的代碼量過多，如果一次待review的代碼量過多，此時整個流程很容易流于形式。因此，這里可以根據(jù)不同團隊的實際情況，定義好單次code review的耗時，限制在一個時間范圍內(nèi)。

6.3 代碼靜態(tài)掃描規(guī)則的建立

對于一些常見的代碼review的問題，可以制定代碼掃描規(guī)則，在code review之前，先執(zhí)行一次代碼掃描，識別出其中比較常見的問題，減少代碼review的時間。

這樣對于也減輕了reviewer的負擔，也利于開發(fā)者自行發(fā)現(xiàn)問題，自行解決，避免時間的浪費。

6.4 學習和分享

團隊中的成員可以定期分享 Code Review 的經(jīng)驗和技巧，以便更好地提高審查的效率和質(zhì)量。
有這樣一個分享，那么code review這個過程可以作為一個輸入，能夠增加大家code review的參與度。

6.5 反饋和改進

code review的流程，在執(zhí)行過程中，大概率會發(fā)現(xiàn)其中并不合理的地方，或者有待改進的地方，此時應該每隔1個月/2個月，來回顧整個流程，發(fā)現(xiàn)其中不合理的地方，讓code review更好得進行下去。

同時，在code review過程中，也有收集一些code review的數(shù)據(jù)，可以對其進行分析，發(fā)現(xiàn)其中不合理的地方，針對不合理的地方進行改進。

7. 建立code review的流程的實踐過程

7.1 確定團隊目標

首先，團隊建立code reviwe的目標和需求，為什么要code review,有目標了，后續(xù)才能評估code review是否達到了目的。

7.2 時間節(jié)點的確定

首先需要確定code review的時間節(jié)點的安排。是開發(fā)完成后，提測前開始code review還是其他時間節(jié)點呢。code review的時間安排是否包含到項目排期中。

reviewer是否得提前知會，在何時知會? 其是否要參加需求評審以及測試用例評審等項目相關需求的評審會? 以及reviewer在code review過程的所耗工時要怎么統(tǒng)計呢，是不是在項目排期時，也需要考慮到code review的耗時，然后耗時大致的排期，是否設定為開發(fā)時間的10%,還是其他，是否先執(zhí)行，后續(xù)再根據(jù)實際情況調(diào)整呢?

7.3 review平臺以及review形式的確定

上面code review的時間安排已經(jīng)確定好了，之后便需要開始code review,這里需要團隊內(nèi)確定code review的工具，是使用開源工具，如reviewBoard,亦或者是直接gitlab平臺提交mr的時候順便review呢,這個也需要確定。

當平臺確定好之后，我們需要確定review的形式，是開發(fā)和reviewer一起review,reviwer一邊看一遍提問，亦或者是reviewer先整體看一遍，然后有疑問再提出，然后開發(fā)再當面說明，或者是其他形式，這個也是需要確定的。

7.4 review代碼量的確定

之后比較重要的點，便是每次review的代碼量的問題,我們可以想象，如果每次需要review的幾千行的代碼，此時往往review便會流于形式，其實并不會起到太大的作用。這里應該由團隊內(nèi)部協(xié)商好code review的形式，是單次少量，多次review; 還是項目開發(fā)完成之后，再整體review; 或者是兩者的結合,一些項目整體開發(fā)完成之后再review,一些項目采取單次少量，多次review的形式，亦或者是其他。

7.5 review內(nèi)容的確定

接著，就要開始代碼review,這里就需要確定review主要review哪些內(nèi)容，這個示例可以參考第三點所說的，review哪些部分的內(nèi)容，不過還是需要團隊自行確定。不過這里有個前置依賴，團隊需要有一套統(tǒng)一的代碼規(guī)范，如命名規(guī)范等。這里假設已經(jīng)確定review的內(nèi)容包含代碼的可讀性，如果沒有一套統(tǒng)一的規(guī)范，review流程是比較難執(zhí)行下去的。

7.6 數(shù)據(jù)收集方式確定

到這里，我們可以算是完成了一次code review的流程，但是一個流程如果只有執(zhí)行，沒有回顧，那是不太合適的，所以對于code review的流程是需要定時回顧的。當進行回顧時，需要有數(shù)據(jù)來做支撐的，才能識別出整體流程是否存在不合理的地方，那數(shù)據(jù)從哪里來呢?那只能從每次代碼review的過程中獲取。

所以，這里也需要定義每次review流程中，需要記錄下來一些內(nèi)容，方便后續(xù)回顧，具體記錄的內(nèi)容，可以參考第四點制定cr的規(guī)則和流程是什么呢 中第四點的內(nèi)容，然后數(shù)據(jù)記錄的方式也可以統(tǒng)一一下，比如使用飛書文檔或者多維表格，亦或者是其他形式來存儲。方便后續(xù)回顧使用。

7.7 code review如何更好得執(zhí)行

當上面的內(nèi)容都確定好之后，在我看來，一個code review的流程其實就已經(jīng)完成了，這個時候便可以考慮如何讓code review整個流程跑得更順暢，這里可以參考第六點如何讓code review跑起來中的內(nèi)容，比如使用checkList來減輕心智負擔，其次可以建立靜態(tài)掃描規(guī)則集，能夠減少code review的工作量等。

7.8 定時回顧

然后再定時回顧整個code review的流程，發(fā)現(xiàn)其中不合理的地方，再對其進行改進。

8. 總結

該文檔是一篇關于Code Review的輸出，介紹了Code Review的規(guī)則和流程需要包含的內(nèi)容，以及具體需要Review的內(nèi)容。此外，還描述了一些在Review過程中需要遵守的原則，如尊重，建議等，以保持Review的積極性和有效性。
最后，列舉了一些方式，如定期進行Review、使用靜態(tài)代碼掃描工具、checklist來進行code review，進行學習和分享，能夠讓Code Review更好地執(zhí)行下去。文章來源地址http://www.zghlxwxcb.cn/news/detail-414374.html

到了這里，關于為什么要code review的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！