Code Review

• 提高代碼質(zhì)量
• 提前發(fā)現(xiàn)bug
• 統(tǒng)一代碼規(guī)范
• 提高團(tuán)隊(duì)成員代碼技能

總之，前期找問題（代碼規(guī)范、潛在缺陷、BUG，代碼設(shè)計(jì)等等），后期演變成開發(fā)者技術(shù)交流和員工成長(zhǎng)

如何開展

• 代碼規(guī)范：明確Coding規(guī)則
• 檢視清單：結(jié)合業(yè)務(wù)特點(diǎn)，check重點(diǎn)
• 總結(jié)優(yōu)化：透明問題，持續(xù)優(yōu)化
• 激勵(lì)措施：激發(fā)主觀能動(dòng)性

開展方式

• 強(qiáng)制&非強(qiáng)制
• 線上交流（小組review）&線下會(huì)議（團(tuán)隊(duì)review）
• 小片段&大模塊
• 發(fā)布前&發(fā)布后
• 高頻率&低頻率

阻力因素

1. 領(lǐng)導(dǎo)或者團(tuán)隊(duì)骨干不認(rèn)同
2. 為了疲于應(yīng)付
3. 以需求多，沒時(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)代碼檢查工具

1. Java類：Checkstyle、FindBugs、PMD、Infer等
2. JavaScript類：JSLint、ESLint等
3. Object-C類：OCLint、Clang Static Analyzer、Infer等
4. **C#**類：StyleCode等

可以參考的一些編碼規(guī)范(github.com/Kristories/…)

發(fā)現(xiàn)『bad smell』的代碼以及bug

相關(guān)書籍：《重構(gòu)-改善既有代碼的設(shè)計(jì)》《代碼整潔之道》

團(tuán)隊(duì)成員好的經(jīng)驗(yàn)

• 什么寫法可能導(dǎo)致性能低下？
• 哪個(gè)接口要慎用？
• 哪些設(shè)計(jì)方式需要規(guī)避？
• 什么習(xí)慣容易引發(fā)內(nèi)存泄漏？ ……

開發(fā)者由于當(dāng)初時(shí)間緊迫而覺得設(shè)計(jì)不合理的功能

• 功能不完善
• 設(shè)計(jì)有欠缺
• 代碼有更好實(shí)現(xiàn)方案
• 重視項(xiàng)目代碼的可讀性

總之，代碼是否符合團(tuán)隊(duì)約定的代碼風(fēng)格規(guī)范、代碼是否切合它所實(shí)現(xiàn)的業(yè)務(wù)、代碼是否安全、代碼性能、對(duì)后續(xù)開發(fā)者是否友好，即是否容易維護(hù)等

注意事項(xiàng)

1. GitLab可以設(shè)置master和develop分支保護(hù)，開發(fā)者不能向這兩個(gè)分支push代碼，只能通過PR/MR形式。
2. 可以通過設(shè)置git pre-commit hook來check，從而使不符合規(guī)范的代碼禁止提交倉(cāng)庫(kù)。
3. 配合CI檢查，作為build的第一步。
4. 用戶角色有：所有者/主程/開發(fā)者/報(bào)告者/訪客，其中只有所有者和主程才有review代碼和合并代碼權(quán)限。
5. 注意小組至少有兩個(gè)人有權(quán)限r(nóng)eview并合并代碼，避免一個(gè)人請(qǐng)假或者不在，導(dǎo)致代碼合不上去。
6. 主程一定要注意，避免過多模塊工作堆積在自己身上，一定要學(xué)會(huì)合理分配任務(wù)，因?yàn)槟氵€需要有精力去review代碼，這也是一部分額外任務(wù)。
7. 提交的 feature 分支全部走 gitlab 的 MR ，develop分支不允許提交，只用來合并，并且只合并那些經(jīng)過review過的代碼，master分支不允許提交，也只用來合并，并且只合并來自develop分支的代碼。
8. 不一定職稱越高，就更有可能比別人review代碼，code review知識(shí)共享更受重視，通過review發(fā)現(xiàn)bug是有的，但不是最終目的，增進(jìn)團(tuán)隊(duì)共識(shí)，保護(hù)團(tuán)隊(duì)一致性其實(shí)更重要。
9. 盡量避免開發(fā)經(jīng)驗(yàn)不足的開發(fā)者或者剛進(jìn)公司對(duì)業(yè)務(wù)不熟悉的人員（哪怕高級(jí)工程師）review 代碼。
10. 如果可以盡可能寫單元測(cè)試，不一定cover全面，如果時(shí)間緊迫可以只對(duì)關(guān)鍵模塊做。
11. 提交PR/MR，記得在IM上通知相關(guān)人員review，比如項(xiàng)目負(fù)責(zé)人或者模塊負(fù)責(zé)人。
12. 控制團(tuán)隊(duì)review的時(shí)間，半個(gè)小時(shí)到1個(gè)小時(shí)，最好不要超過1個(gè)小時(shí)，30-40分鐘為宜，項(xiàng)目負(fù)責(zé)人具體把握。
13. 根據(jù)公司情況團(tuán)隊(duì)review一周在至少一次比較合適。
14. review可能需要多次才被允許合入代碼，這也就意味著，可能你的代碼需要給多次修改才能改好。
15. 避免代碼堆積，造成一次review大量代碼，一方面急于review，這樣容易放水，同時(shí)也浪費(fèi)時(shí)間，造成效果不理想。
16. 建議由1人做好記錄，把每次review的改進(jìn)點(diǎn)以清單形式匯總列清楚發(fā)給所有參會(huì)人員。

總結(jié)

由于工期緊、需求變更快，如果不想清楚為什么要做 Code Review ，遇到障礙會(huì)非常容易妥協(xié)，慢慢 Code Review 就會(huì)走樣，最終流于形式。反之，在我們遇到障礙，review 代碼不順利時(shí)就會(huì)以積極的心態(tài)來解決問題。Code Review會(huì)影響開發(fā)效率，事實(shí)上追求高質(zhì)量的代碼本身就降低了局部的開發(fā)效率，但是放眼長(zhǎng)遠(yuǎn)，這樣寫出來的代碼更加健壯，不會(huì)或很少出現(xiàn)“詭異”的bug，降低了后期維護(hù)的成本。

所以Code Review本身沒有問題，其實(shí)是人容易出問題。

總結(jié)

以上是生活随笔為你收集整理的关于Code Review的一些思考总结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。