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

静态代码检查工具StyleCode。

 

 

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

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

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

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

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

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

 

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