CodeReview 规范
目标和原则
- 提高代码质量,及早发现潜在缺陷,降低修改/弥补缺陷的成本
- 促进团队内部知识共享,提高团队整体水平
- 评审过程对于评审人员来说,也是一种思路重构的过程,帮助更多的人理解系统
- 是一个传递知识的手段,可以让其它并不熟悉代码的人知道作者的意图和想法,从而可以在以后轻松维护代码
- 可以被用来确认自己的设计和实现是一个清楚和简单的
- 鼓励相互学习对方的长处和优点
- 高效迅速完成Code Review
Code Review的步骤
- 代码编写者和代码审核者坐在一起,由代码编写者按照UC依次讲解自己负责的代码和相关逻辑,从Web层->DAO层;
- 代码审核者在此过程中可以随时提出自己的疑问,同时积极发现隐藏的bug;对这些bug记录在案。
- 代码讲解完毕后,代码审核者给自己安排几个小时再对代码审核一遍。代码需要一行一行静下心看。同时代码又要全面的看,以确保代码整体上设计优良。
- 代码审核者根据审核的结果编写“代码审核报告”,“审核报告”中记录发现的问题及修改建议,然后把“审核报告”发送给相关人员。
- 代码编写者根据“代码审核报告”给出的修改意见,修改好代码,有不清楚的地方可积极向代码审核者提出。
- 代码编写者 bug fix完毕之后给出反馈。
- 代码审核者把Code Review中发现的有价值的问题更新到"代码审核规范"的文档中,对于特别值得提醒的问题可群发email给所有技术人员。
备注:
Code Review必备的文档:
“Code Review规范”文档:记录代码应该遵循的标准。
代码审核者根据这些标准来Code Review代码,同时在Code Review过程中不断完善该文档。
Code Review的执行
准备阶段
- 需要在提交测试前进行Code Review;
- 在提交CodeReview前,代码需要通过本地 SonarLint 与 Alibaba GuideLines(编码规约插件检查)检查;
- 通知同开发组内成员进行Code Review;
- 将代码地址发布到群里(后续发CR工具生成的地址);
- 开启Git中半数通过的合并机制吧;
实施阶段
充分的事前准备,只是做好CR活动的前提,在CR实施过程中,我们要做好以下工作。
- 提交人员需要对重点代码进行讲解、并针对审核人员提出的问题进行解答;
- 对于CR过程发现的问题,我们必须清晰准确的记录,可以使用问题点记录单,明确记录的项目和内容。
- CR过程中,要采用代码作者讲解和审查者提问方式。审查者不能只在发现问题时提问,同时也要根据本次审查的内容要求代码作者对某个特定问题的讲解。
- 对事前确定的审查内容,要逐项审查,不能因为时间不足等因素一扫而过。
- 实施审查时,要营造一个讨论问题、解决问题的氛围,不能把审查会搞成批判会,这样会影响相关人员的积极性。
事后跟踪
- 对问题修改后,需要找问题提出人确认修复完成后,才能将代码合并到测试分支;
- 提交测试申请邮件中,填写负责CR的同学;
- 提测同学不能自己提交Git中的Merge请求;
注意事项
- 经常进行Code Review
(1)要Review的代码越多,那么要重构,重写的代码就会越多。而越不被程序作者接受的建议也会越多,唾沫口水战也会越多。
(2)程序员代码写得时候越长,程序员就会在代码中加入越来越多的个人的东西。
(3)越接近软件发布的最终期限,代码也就不能改得太多。
- Code Review不要太正式,而且要短
忘了那个代码评审的Checklist吧,走到你的同事座位跟前,像请师父一样请他坐到你的电脑面前,然后,花5分钟给他讲讲你的代码,给他另外一个5分钟让他给你的代码提提意见,这比什么都好。而如果你用了一个Checklist,让这个事情表现得很正式的话,下面两件事中必有一件事会发生:
(1)只有在Checklist上存在的东西才会被Review。
(2)Code Reviews 变成了一种礼节性的东西,你的同事会装做很关心你的代码,但其实他心里想着尽快地离开你。
只有不正式的Code Review才会让你和评审者放轻松,人只有放松了,才会表现得很真实,很真诚。记住Review只不过是一种形式,而只有在相互信任中通过相互的讨论得到了有意义和有建设性的建议和意见,那才是最实在的。不然,作者和评审者的关系就会变成小偷和警察的关系。
- 尽可能的让不同的人Review你的代码
如果可能的话,不要总是只找一个人来Review你的代码,不同的人有不同的思考方式,有不同的见解,所以,不同的人可以全面的从各个方面评论你的代码。
但不要太多了,人多嘴杂反而适得其反,基本上来说,不要超过3个人,这是因为,这是一个可以围在一起讨论的最大人员尺寸。
下面是几个优点:
(1)从不同的方向评审代码总是好的。
(2)会有更多的人帮你在日后维护你的代码。
(3)这也是一个增加团队凝聚力的方法。
- 保持积极的正面的态度
程序员最大的问题就是“自负”,尤其当我们Review别人的代码的时候,我已经见过无数的场面,程序员在Code Review的时候,开始抨击别人的代码,质疑别人的能力。太可笑了,我分析了一下,这类的程序员其实并没有什么本事,因为他们指责对方的目的是想告诉大家自己有多么的牛,靠这种手段来表现自己的程序员,其实是就是传说中所说的“半瓶水”。
所以,无论是代码作者,还是评审者,都需要一种积极向上的正面的态度,作者需要能够虚心接受别人的建议,因为别人的建议是为了让你做得更好;评审者也需要以一种积极的正面的态度向作者提意见,因为那是和你在一个战壕里的战友。记住,你不是一段代码,你是一个人!
- 学会享受Code Review
这可能是最重要的一个提示了,如果你到了一个人人都喜欢Code Review的团阿,那么,你会进入到一个生机勃勃的地方,在那里,每个人都能写出质量非常好的代码,在那里,你不需要经理的管理,团队会自适应一切变化,他们相互学习,相互帮助,不仅仅是写出好的代码,而且团队和其中的每个人都会自动进化,最关键的是,这个是一个团队。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· 上周热点回顾(2.17-2.23)
· 如何使用 Uni-app 实现视频聊天(源码,支持安卓、iOS)
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)