提到Code Review(CR),就和单元测试一样,虽然一直在提倡,大家也都知道他的重要性,但是实践起来总是差点意思,有个说法是CR就和鬼一样,一直有他的传说,但一直没有见到过。本文梳理下团队目前在做的CR实践,做点沉淀。
01
目标是什么?
任何活动都有它的目标,CR也不例外,对于CR,团队给出的目标是:为了保证公司整体代码的健康状况随着不断迭代,始终保持一个较高的水平,希望通过规范化代码评审及其过程,可以提高代码质量、减少错误、促进团队合作和知识分享,提高软件开发的效率和质量。
从这个目标中,就可以看出CR的种种好处(其实大家都能看得到,只是无法保证落地):
02
有效地保障机制
如上图所示,为了保证CR的持续落地,形成规范,团队建立了有效的机制来保障这一活动不走样,不流于形式:
03
评审过程中的策略
在评审过程中,要特别注意不能把代码问题升级成为人的问题,组织者要特别注意引导和及时地提醒,在评审过程中,建议:
04
成果展示
CR在团队中的落地已经有一段时间了,这个活动将持续进行下去,目前发现的问题数如下:
可以看到,评审过程发现的代码缺陷和性能类其实并不多,更多的是集中在代码规范和代码优化上,这也符合对CR的预期。不能寄希望于CR能发现多少缺陷,因为这本身就是类似于静态代码检查。
代码评审记录表如下图所示:
05
CR的积极意义大家都懂,如何落地取决于团队的负责的决心及团队成员对代码的自我要求程度。取决于你做不做。
共勉。