6.我们真的做了代码评审

Posted efwplus

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了6.我们真的做了代码评审相关的知识,希望对你有一定的参考价值。

静态代码检查工具StyleCode。

 

 

    上一章我说了设计评审和测试用例评审都是为了提升产品质量问题,后来我们又做了代码评审,但是代码评审比设计评审难搞多了,对于开发来说最在意的就是自己的代码,让别人对自己的代码指指点点,虽然是好的建议但也会让人不爽。

    准备搞代码评审之前以前就尝试过,搞着搞着最后的结果只是变成一种形式而已,大家热情都不高,反而给团队增加了负面的情绪。在现在团队中由于代码质量问题,减少bug的产出,在回顾会议中团队提出可以试一下代码评审,是对这个解决办法存在担忧的。我们采用stylecode工具来做静态代码检查,我们最后做到了零问题,基本上迭代完成前开发人员都会把stylecode检查出来的问题清理掉。静态代码检查可以保证大家代码编写的规范与一些基本问题,但一些深层次的业务逻辑问题是发现不了的,所以还是得靠人来手动检查。刚开始为了减少团队在代码评审中的矛盾,鼓励大家分享自己写得好的代码,而不是大家一起来找茬。比如H君写了一个公共方法大家都有可能用到,Y君在使用某个控件中碰到的一些问题等等。通过这个会议来加强开发的分享,同时我们使用有道云笔记建立了团队的知识分享小组,这样大家在碰到一个已经解决的问题可以从中查找。

    代码评审我们一个迭代做两次,第一周的周五下午2个小时,第二周的周四下午2个小时,在第一个周五的时候基本大家都有故事完成了,所以提前进行代码评审,因为如果全拖到第二周的话,可能有些问题没有能提早发现,导致越到后面发现的话修改的代价更大一些,还有就是全部开发完成再做的话花费的时间会更长。第二周的话基本上周四开发都已经完成自己的故事,周五上午做集成测试,下午开迭代评审会议和回顾会议。

    我一般建议大家在讲自己的代码的之前,一定要组织好自己的语言,提前过一遍或者准备几张时序图,这样在讲解的时候更有条理性,自己讲都讲不清的话,可想而知代码的质量也只有这么好。另外针对核心算法画的时序图可以补充到之前做得设计文档中去,完成设计文档。还有就是一些有问题的代码和好的代码都会记录下来,好的编写知识分享,不好的记录跟踪,持续改进。

    我们还尝试过一些其他的代码评审方式,比如在代码提交前由开发主管统一评审,只有评审通过后的代码才能commit,后来发现这种方式比好执行,一下就拉下了团队的开发速度,然后就是开发主管也没有这么过精力来做这件事情,所以做出来的效果也不咋的。接下来我们想尝试开发之间相互评审对方的代码,这样能更多的深入到代码本质,但同时也对团队的要求更高,所以得一步一步来,持续改进。

    做这个代码评审确实还是给团队好的方面,代码的分享确实提高了解决问题的效率,碰到的一些技术问题,如果之前有人碰到过,那基本很快就能解决。不用自己独自浪费时间来研究解决。再有就是对新人的帮助很大,新人会在这个会议上更好的学习框架的使用,功能代码的实现与获得问题的详细解答。

 

    总之,我觉得代码评审确实可以提升产品质量与提升团队开发能力,但是一定要注意方法方式,不能操之过急与生搬硬套。

以上是关于6.我们真的做了代码评审的主要内容,如果未能解决你的问题,请参考以下文章

麻省理工18年春软件构造课程阅读04“代码评审”

用GitLab的Merge Request做代码评审

软件项目简明代码评审流程

自动提交Git branch代码评审到Review Board系统

需求评审之隐性需求

实验四 代码评审