怎麼做code review

我們現在的code review的方式是在提測前甚至在提測後，開始review，這樣有幾個弊端：

1. 一次性進行很大批量的code review，是review不出來什麼東西的，隻能看看最表面

2. 在提測之前或者提測之後進行code review，如果是比較大的問題，或者review出來的問題比較多，相關開發修改的時間是有限的

   是以，更加推薦使用pr（mr）級别的code review。

   先介紹一下code review的好處

   團隊知識共享：

3. 通過代碼審查，高手可以直接指出新手代碼中的問題，新手可以馬上從高手的回報中學習到好的實踐，得到更快的成長
4. 新人成長了，可以幫老人多分擔一些任務
5. 代碼審查中花了時間，就可以減少後續一些幫新人做的業務擦屁股的時間

6. 良好的溝通、發現問題的能力、幫助其他人成長都是技術上更上一層樓必不可少的能力，通過代碼審查可以有效提升這些能力

   提升代碼品質

7. 提升代碼的可讀性、可維護性
8. 一些特定條件下的隐患或者安全漏洞，可能測試都無法測試出來，代碼審查卻可以發現

9. 高手也需要代碼被審查：（1）别人通過閱讀高手的代碼，可以學習到很多好的編碼實踐（2）高手的代碼肯定也有一些問題的，就像考試中，學習好的學生也要在寫完試卷後，自己檢查一遍

   編碼規範

10. 我發現很多人有時候，明知寫的代碼不符合編碼規範，但是因為沒有人審查他們的代碼，寫代碼是“明知故犯”（寫一段行數很長的方法、故意用變量而不用常量）

11. 有了代碼審查機制，寫代碼的人就會心裡有杆秤，會盡量把代碼寫規範，因為知道有人要review自己的代碼

    降低維護成本

    我們開發的代碼，如果寫的不好，開發用了2天，可能在後續的疊代和查找線上問題的時候，要多花5天去維護

    現在都有什麼code review的方式？

    現在code review的方式有哪幾種：

    • 面對面：reviewer和author一起面對面檢視代碼，代碼有問題，reviewer直接指出，author後面修改，這種方式要兩個人一起review，消耗掉了所有reviewer和author的時間，優點是面對面溝通更直接

    • 設定栅欄：就是author在自己的開發分支開發，在合并到測試分支的時候在gitlab送出一個mr請求，code reviewer進行code review，如果有問題提出來問題，問題修改掉後再合并到測試分支，設定栅欄有一個優點是，讓送出代碼者心裡有了敬畏，知道代碼是要被review的，并且要review通過才能合并到測試分支的，讓review者平時寫代碼的時候不敢再輕易寫出爛代碼。

    • 不設栅欄：author先送出代碼到測試分支，在後續reviewer再進行code review，這個方案的缺點是：開發者可以随意往測試分支送出代碼，code reviewer後續找時間review，這種方式可能導緻送出到測試分支的代碼是有問題的，後續提出了代碼問題，author修不修改都看author自己。

    怎麼樣做code review?

    總和比較後，我比較傾向于使用“開發階段設栅欄，提測後不設栅欄”的方式進行code review

12. 每個人都有自己的開發分支，設定測試分支的push權限
13. 在gitlab上，可以設定指定的分支隻有master等級的開發者才能推送到指定分支
14. merge request并標明送出人
15. 代碼稽核人發表代碼審查的意見，全部修改後，将問題置為resolved，當所有問題都被解決後，稽核人點選merge按鈕即可
16. 所有人在gitlab上把代碼merge request到測試分支，1-2天一次，在pull request後相關人員code review代碼，如果code review通過則merge到測試分支，如果review不通過，則在gitlab上面标記出來問題，問題分為兩個等級：error：必須要修改的，warn：建議修改的，
17. code review是互相學習進步的方式，不要帶有貶低損的詞彙口吻
18. 開發在排期的時候就要把相關code review的人員想好，并在排期的時候将code review的時間排進去，以每兩天一次code review，一次1小時為标準
19. 以上流程在開發過程中是沒有問題的，如果在提測後，還要code review後才能merge到測試分支，反應就有些慢了，會影響測試的進度了，此時可以，在測試環境修改測試分支的權限，devloper可以送出推送到測試分支，還是2天code review一次，但是先測試環境釋出，後code review。
20. 根據個人習慣，還可以通過idea插件安裝代碼審查gitlab代碼審查的功能我們現在的code review的方式是在提測前甚至在提測後，開始review，這樣有幾個弊端：
21. 一次性進行很大批量的code review，是review不出來什麼東西的，隻能看看最表面

22. 在提測之前或者提測之後進行code review，如果是比較大的問題，或者review出來的問題比較多，相關開發修改的時間是有限的

    是以，更加推薦使用pr（mr）級别的code review。

    先介紹一下code review的好處

    團隊知識共享：

23. 通過代碼審查，高手可以直接指出新手代碼中的問題，新手可以馬上從高手的回報中學習到好的實踐，得到更快的成長
24. 新人成長了，可以幫老人多分擔一些任務
25. 代碼審查中花了時間，就可以減少後續一些幫新人做的業務擦屁股的時間

26. 良好的溝通、發現問題的能力、幫助其他人成長都是技術上更上一層樓必不可少的能力，通過代碼審查可以有效提升這些能力

    提升代碼品質

27. 提升代碼的可讀性、可維護性
28. 一些特定條件下的隐患或者安全漏洞，可能測試都無法測試出來，代碼審查卻可以發現

29. 高手也需要代碼被審查：（1）别人通過閱讀高手的代碼，可以學習到很多好的編碼實踐（2）高手的代碼肯定也有一些問題的，就像考試中，學習好的學生也要在寫完試卷後，自己檢查一遍

    編碼規範

30. 我發現很多人有時候，明知寫的代碼不符合編碼規範，但是因為沒有人審查他們的代碼，寫代碼是“明知故犯”（寫一段行數很長的方法、故意用變量而不用常量）

31. 有了代碼審查機制，寫代碼的人就會心裡有杆秤，會盡量把代碼寫規範，因為知道有人要review自己的代碼

    降低維護成本

    我們開發的代碼，如果寫的不好，開發用了2天，可能在後續的疊代和查找線上問題的時候，要多花5天去維護

    現在都有什麼code review的方式？

    現在code review的方式有哪幾種：

    • 面對面：reviewer和author一起面對面檢視代碼，代碼有問題，reviewer直接指出，author後面修改，這種方式要兩個人一起review，消耗掉了所有reviewer和author的時間，優點是面對面溝通更直接

    • 設定栅欄：就是author在自己的開發分支開發，在合并到測試分支的時候在gitlab送出一個mr請求，code reviewer進行code review，如果有問題提出來問題，問題修改掉後再合并到測試分支，設定栅欄有一個優點是，讓送出代碼者心裡有了敬畏，知道代碼是要被review的，并且要review通過才能合并到測試分支的，讓review者平時寫代碼的時候不敢再輕易寫出爛代碼。

    • 不設栅欄：author先送出代碼到測試分支，在後續reviewer再進行code review，這個方案的缺點是：開發者可以随意往測試分支送出代碼，code reviewer後續找時間review，這種方式可能導緻送出到測試分支的代碼是有問題的，後續提出了代碼問題，author修不修改都看author自己。

    怎麼樣做code review?

    總和比較後，我比較傾向于使用“開發階段設栅欄，提測後不設栅欄”的方式進行code review

32. 每個人都有自己的開發分支，設定測試分支的push權限
33. 在gitlab上，可以設定指定的分支隻有master等級的開發者才能推送到指定分支
34. merge request并標明送出人
35. 代碼稽核人發表代碼審查的意見，全部修改後，将問題置為resolved，當所有問題都被解決後，稽核人點選merge按鈕即可
36. 所有人在gitlab上把代碼merge request到測試分支，1-2天一次，在pull request後相關人員code review代碼，如果code review通過則merge到測試分支，如果review不通過，則在gitlab上面标記出來問題，問題分為兩個等級：error：必須要修改的，warn：建議修改的，
37. code review是互相學習進步的方式，不要帶有貶低損的詞彙口吻
38. 開發在排期的時候就要把相關code review的人員想好，并在排期的時候将code review的時間排進去，以每兩天一次code review，一次1小時為标準
39. 以上流程在開發過程中是沒有問題的，如果在提測後，還要code review後才能merge到測試分支，反應就有些慢了，會影響測試的進度了，此時可以，在測試環境修改測試分支的權限，devloper可以送出推送到測試分支，還是2天code review一次，但是先測試環境釋出，後code review。
40. 根據個人習慣，還可以通過idea插件安裝代碼審查gitlab代碼審查的功能