Code Review
目的
提高代碼質(zhì)量
提前發(fā)現(xiàn)bug
統(tǒng)一代碼規(guī)范
提高團(tuán)隊(duì)成員代碼技能
前期找問(wèn)題（代碼規(guī)范呕童、潛在缺陷、BUG，代碼設(shè)計(jì)等等）哈街，后期演變成開(kāi)發(fā)者技術(shù)交流和員工成長(zhǎng)
如何開(kāi)展
代碼規(guī)范：明確Coding規(guī)則
檢視清單：結(jié)合業(yè)務(wù)特點(diǎn)，check重點(diǎn)
總結(jié)優(yōu)化：透明問(wèn)題如庭，持續(xù)優(yōu)化
激勵(lì)措施：激發(fā)主觀能動(dòng)性
開(kāi)展方式
強(qiáng)制&非強(qiáng)制
線上交流（小組review）&線下會(huì)議（團(tuán)隊(duì)review）
小片段&大模塊
發(fā)布前&發(fā)布后
高頻率&低頻率
阻力因素
領(lǐng)導(dǎo)或者團(tuán)隊(duì)骨干不認(rèn)同
為了疲于應(yīng)付
以需求多叹卷，沒(méi)時(shí)間做為偷懶借口
組織類型
小組內(nèi)review，通常是模塊負(fù)責(zé)人或者項(xiàng)目負(fù)責(zé)人review坪它，頻率比較高骤竹，一天至少一次
團(tuán)隊(duì)review，通常是整個(gè)團(tuán)隊(duì)review代碼往毡，團(tuán)隊(duì)負(fù)責(zé)人牽頭蒙揣，頻率可以低一點(diǎn)，鑒于公司情況一周至少1次吧
review內(nèi)容
統(tǒng)一團(tuán)隊(duì)代碼風(fēng)格和編程規(guī)范
靜態(tài)代碼檢查工具
Java類：Checkstyle开瞭、FindBugs懒震、PMD、Infer等
JavaScript類：JSLint嗤详、ESLint等
Object-C類：OCLint个扰、Clang Static Analyzer、Infer等
C#類：StyleCode等
……
更多可以參考的一些編碼規(guī)范(Kristories/awesome-guidelines)
發(fā)現(xiàn)『bad smell』的代碼以及bug
相關(guān)書(shū)籍：《重構(gòu)-改善既有代碼的設(shè)計(jì)》《代碼整潔之道》
團(tuán)隊(duì)成員好的經(jīng)驗(yàn)
什么寫(xiě)法可能導(dǎo)致性能低下葱色？
哪個(gè)接口要慎用递宅？
哪些設(shè)計(jì)方式需要規(guī)避？
什么習(xí)慣容易引發(fā)內(nèi)存泄漏苍狰？
……
開(kāi)發(fā)者由于當(dāng)初時(shí)間緊迫而覺(jué)得設(shè)計(jì)不合理的功能
功能不完善
設(shè)計(jì)有欠缺
代碼有更好實(shí)現(xiàn)方案
重視項(xiàng)目代碼的可讀性
總之办龄，代碼是否符合團(tuán)隊(duì)約定的代碼風(fēng)格規(guī)范、代碼是否切合它所實(shí)現(xiàn)的業(yè)務(wù)淋昭、代碼是否安全俐填、代碼性能、對(duì)后續(xù)開(kāi)發(fā)者是否友好翔忽，即是否容易維護(hù)等
注意事項(xiàng)
GitLab可以設(shè)置master和develop分支保護(hù)英融，開(kāi)發(fā)者不能向這兩個(gè)分支push代碼，只能通過(guò)PR/MR形式歇式。
可以通過(guò)設(shè)置git pre-commit hook來(lái)check驶悟，從而使不符合規(guī)范的代碼禁止提交倉(cāng)庫(kù)。
配合CI檢查贬丛，作為build的第一步撩银。
用戶角色有：所有者/主程/開(kāi)發(fā)者/報(bào)告者/訪客，其中只有所有者和主程才有review代碼和合并代碼權(quán)限豺憔。
注意小組至少有兩個(gè)人有權(quán)限r(nóng)eview并合并代碼额获，避免一個(gè)人請(qǐng)假或者不在够庙，導(dǎo)致代碼合不上去。
主程一定要注意抄邀，避免過(guò)多模塊工作堆積在自己身上耘眨，一定要學(xué)會(huì)合理分配任務(wù)，因?yàn)槟氵€需要有精力去review代碼境肾，這也是一部分額外任務(wù)剔难。
提交的 feature 分支全部走 gitlab 的 MR ，develop分支不允許提交奥喻，只用來(lái)合并偶宫，并且只合并那些經(jīng)過(guò)review過(guò)的代碼，master分支不允許提交环鲤，也只用來(lái)合并纯趋，并且只合并來(lái)自develop分支的代碼。
不一定職稱越高冷离，就更有可能比別人review代碼吵冒，code review知識(shí)共享更受重視，通過(guò)review發(fā)現(xiàn)bug是有的西剥，但不是最終目的痹栖，增進(jìn)團(tuán)隊(duì)共識(shí)，保護(hù)團(tuán)隊(duì)一致性其實(shí)更重要瞭空。
盡量避免開(kāi)發(fā)經(jīng)驗(yàn)不足的開(kāi)發(fā)者或者剛進(jìn)公司對(duì)業(yè)務(wù)不熟悉的人員（哪怕高級(jí)工程師）review 代碼揪阿。
如果可以盡可能寫(xiě)單元測(cè)試，不一定cover全面匙铡，如果時(shí)間緊迫可以只對(duì)關(guān)鍵模塊做图甜。
提交PR/MR碍粥，記得在IM上通知相關(guān)人員review鳖眼，比如項(xiàng)目負(fù)責(zé)人或者模塊負(fù)責(zé)人。
控制團(tuán)隊(duì)review的時(shí)間嚼摩，半個(gè)小時(shí)到1個(gè)小時(shí)钦讳，最好不要超過(guò)1個(gè)小時(shí)，30-40分鐘為宜枕面，項(xiàng)目負(fù)責(zé)人具體把握愿卒。
根據(jù)公司情況團(tuán)隊(duì)review一周在至少一次比較合適。
review可能需要多次才被允許合入代碼潮秘，這也就意味著琼开，可能你的代碼需要給多次修改才能改好。
避免代碼堆積枕荞，造成一次review大量代碼柜候，一方面急于review搞动，這樣容易放水，同時(shí)也浪費(fèi)時(shí)間渣刷，造成效果不理想鹦肿。
建議由1人做好記錄，把每次review的改進(jìn)點(diǎn)以清單形式匯總列清楚發(fā)給所有參會(huì)人員辅柴。
總結(jié)
由于工期緊箩溃、需求變更快，如果不想清楚為什么要做 Code Review 碌嘀，遇到障礙會(huì)非常容易妥協(xié)涣旨，慢慢 Code Review 就會(huì)走樣，最終流于形式股冗。反之拔疚，在我們遇到障礙，review 代碼不順利時(shí)就會(huì)以積極的心態(tài)來(lái)解決問(wèn)題怎囚。Code Review會(huì)影響開(kāi)發(fā)效率秦陋，事實(shí)上追求高質(zhì)量的代碼本身就降低了局部的開(kāi)發(fā)效率，但是放眼長(zhǎng)遠(yuǎn)导俘，這樣寫(xiě)出來(lái)的代碼更加健壯峦耘，不會(huì)或很少出現(xiàn)“詭異”的bug，降低了后期維護(hù)的成本旅薄。
所以Code Review本身沒(méi)有問(wèn)題辅髓，其實(shí)是人容易出問(wèn)題。
