關於code review
背景：我們組是屬於技術平臺，後端一共就4個研發，主要是給整個部門提供基礎庫，以及解決方案，所以程式碼量不多，對程式碼要求質量比較高，組內成員整體水平也比較高，有行業天花板的大佬。
純技術團隊：
review關注點：
1.架構設計，重點關注是不是最優，而不單純只是合理
2.程式碼質量，重點關注有沒有可能引發bug之類的
3.是否符合預期，是否考慮到特殊場景
review過程：
1.程式碼量少，所以我們都是有功能要釋出了才review，沒有提前做準備之類的。
2.review過程總有碰到意見不一致的時候，一般就單獨拉出來，群裡大家討論。討論之後很少出現意見不一致的情況，因為組內有幾個大佬存在，一般意見都能達成統一。並且組內氛圍也很好，不會出現互相diss，誰不服誰的情況。
同時我們組也會給業務研發團隊做一些code review。
code review要求：
1.在提交給我們組review之前，必須先把sonar上報的問題給解決了。
2.最好是組核心心成員能先review，對於有爭議的部分，拉出來給我們組review。
3.一次review的程式碼不能太多，保持在幾百行之內，不要上來就上千行程式碼。
4.如果真的模組很大功能很多，可以拆分成小功能小模組進行review。
5.review時間點，一定不是上線前，也不是測試驗收後，而是在開發過程中，逐步review，不是交付之後才review。
6.reviewer要了解被review程式碼的業務，可以不是非常深入，但是至少要了解。
7.reviewer可以是同級，也可以是組內專家，也可以是外援
review重點關注的點：
1.保持程式碼風格一致
2.程式碼是否與需求保持一致，能否達到產品/業務預期
3.程式碼是否有最佳化空間，比如是否需要重構、有更好的設計模式、有更好的寫法
4.是否存在隱藏的bug，包括程式碼本身的bug以及業務邏輯的bug
review過程：
1.研發在提出mr之後，進行review，可以是1v1，或者幾個人找個會議室。推薦就在工位上，一起review，一起討論，有問題的直接寫評論。
2.提mr的研發，一定要提前通知reviewer，而不是提個mr，丟給reviewer就不管了(出現過這種情況，丟個mr連結，@reviewer，就忙自己的事兒去了)
3.review的工具使用gitlab，而不是在程式碼裡新增註釋/TODO之類的。
4.意見不一致的時候，寫個評論標註一下，後續私下再深入研究或者找專家討論都可以。
5.review結束之後，研發修改完問題，如果是簡單的問題，就直接approve進master，如果是比較大的改動，需要reviewer再次確認。
6.一定要針對問題，不要針對人，要保持謙虛和氣。review是互相學習的過程。