把Code Review 作為開發流程的必選項後，不代表Code Review這件事就可以執行的很好，因為Code Review 的執行，很大部分程度上依賴於審查者的認真審查，以及被審查者的積極配合，兩者缺一不可！ ...
把Code Review變成一種開發文化而不僅僅是一種制度
把Code Review 作為開發流程的必選項後，不代表Code Review這件事就可以執行的很好，因為Code Review 的執行，很大部分程度上依賴於審查者的認真審查，以及被審查者的積極配合，兩者缺一不可！
如果僅僅只是當作一個流程制度，那麼就可能會流於形式。最終結果就是看起來有Code Review，但沒有人認真審查，隨便看下就通過了，或者發現問題也不願意修改。
真要把Code Review這件事做好，必須讓Code Review變成團隊的一種文化，開發人員從心底接受這件事，並認真執行這件事。
要形成這樣的文化，不那麼容易，也沒有想象的那麼難，比如這些方面可以參考：
- 首先，得讓開發人員認識到Code Review這件事為自己、為團隊帶來的好處
- 然後，得要有幾個人做好表率作用，榜樣的力量很重要
- 還有，對於管理者來說，你激勵什麼，往往就會得到什麼
- 最後，像寫自動化測試一樣，把Code Review要作為開發任務的一部分，給審查者和被審查者都留出專門的時間去做這件事，不能光想著馬兒跑得快又捨不得給馬兒吃草
如何形成這樣的文化，有心的話，還有很多方法可以嘗試。只有真正讓大家都認同和踐行，才可能去做好Code Review這件事。
自動化工具及規則
前端代碼規範
- eslint config
- coding里增加eslint的掃描
掃出來問題很多：後端也在改，每個迭代修改幾類。這個需要大家看看是否參考後端的方式，定期梳理一批
提交MR前的必要條件
- 先設計再編碼
建議大家在做複雜功能設計之前可以內部先簡單進行一輪頭腦碰撞，看一下是否思路可行，或者大家可以一起看一下是否有更好的實現方案。否則review的時候大部分邏輯都寫完了，如果有更好的方案，不一定能在review的時候再提出修改了，就算提出了，也可能會涉及大量代碼的重寫，最終耽誤工期。
- 本地代碼通過eslint審查
在提交代碼前，請確保error、warning都已處理完畢。有必要忽略eslint校驗時可以考慮使用
/* eslint-disable */
/* eslint-disable no-param-reassign */
// eslint-disable-next-line，
否則肉眼的力量是有限的
- PR要小
在做Code Review的時候，如果有大量的文件修改，那麼Review起來是很困難的，但如果PR比較小，相對就比較容易Review，也容易發現代碼中可能存在的問題。
有必要的話，可以拆分功能點，分階段提交MR，提交的時候標註僅review還是review+merge
- 開發要預留時間，你的Reviewer也要提前周知預留時間
如何review
對評論進行分級
在做Code Review時，需要針對審查出有問題的代碼行添加評論，如果只是評論，有時候對於被審查者比較難甄別評論所代表的含義，是不是必須要修改。
建議可以對Review的評論進行分級，不同級別的結果可以打上不同的Tag，比如說：
- [blocker]在評論前面加上一個blocker標記，表示這個代碼行的問題必須要修改
- [optional]：在評論前面加上一個[optional]標記，表示這個代碼行的問題可改可不改
- [question]：在評論前面加上一個[question]標記，表示對這個代碼行不理解，有問題需要問，被審查者需要針對問題進行回覆澄清
類似這樣的分級可以幫助被審查者直觀瞭解Review結果，提高Review效率。
文件結構的檢查
- 是否符合代碼工程目前形成的常用文件結構
- 文件命名規範
- 文件放置的位置是否合理（比如demand的組件不能放到teamspace下）
書寫風格
變數
駝峰式命名
let cardList;
let cardListButton;
function getCardList(){}
常量
全部大寫，使用下劃線來分割單詞
const TIMEOUT = 10000;
const MAX_LENGHT = 10;
Function
對應的方法應該使用對應的動詞，例如：
get/set, add/remove, create/destroy, start/stop, insert/delete, begin/end；
駝峰式命名；
構造函數的函數名，採用首字母大寫（InitialCap）；其他函數名，一律首字母小寫。
css規範
命名規範：BEM+ Utility-first
