代码评审的开展思路

先说背景,目前的开发团队一共有好几百号人,划分了许多大小的项目组,但交付的主体还是以合作公司为主的,人员流动比较大,很多项目充斥着新人,当战线特别长的情况下,容易忽视交付质量,上线频频出现一些低级错误。

在这样的背景下,怎样去做代码质量提升的工作?

其实周末我们有个研讨活动,其中也有提到一个观点,所有代码变更是否都需要评审。虽然有些人是反对意见,但我个人是举双手赞成的。我想,无论这个人再厉害都好,但代码就是人写出来的,是个人总有可能会犯错,更不用说很多人是新手,面对的是复杂的系统。

代码评审要开展,这是没有问题的,但怎么操作确实需要仔细想想。我原本的想法是一步到位,先树立一个标杆,希望大多数人能够自发去做这个事情,但发现就是不现实的。

后来想想,这是为什么?主要是很多人还没认识到这个东西的价值,虽然嘴上说是认同的,但是实际上是没有感受到的。所以做这个事情的意愿不强。

我们总说任务分配的时候,要考虑意愿和能力两个方面。意愿比较好,能力比较强,当然是我们最希望看到的。但是这种情况有时候真的是不现实,需要我们应该去引导,最后走进一个正向循环的过程。

要达到一个比较好的效果,只能先把事情做起来,或许得用上行政的命令,无论怎样先做起来,然后慢慢加强改进,引导一部分有意识的人继续把这个事情做好。

我想了想,两个原则。

第一,规则要简单。一开始做,对评审规则的要求一定要比较简单,所以我只是列举了10条,没有明细的指引,也不做过多场景化的解释。虽然这10条严格执行要求也是很高的,但事无巨细的指导,要求太多,在一开始肯定是个灾难。

第二,强调线上平台。我一直强调必须是在线评审,别跟我说你们用线下评审,因为那个过程数据不好跟踪。只有借助一些工具,后续我们才有持续做下去的可能。

开展了以后,如何去跟踪改进?

在起步阶段,前面一个月是要持续关注的,可以做一个简单的评比,看看趋势是怎么样的,有什么人,什么项目比较活跃。下一步呢?我们可能对问题进行整理,然后再对Top问题进行识别分类,这样容易制定改进计划,例如加强某个编码规范,也可以做好一些业务代码上的checklist。

在这个过程中,更重要是希望识别到有意愿做这个事情的人,实现少数人带动多数人。他意识到这是有价值的,值得花时间投入。他发现评审可以发现问题,可以培养新人,进而把项目做得更加轻松。下一步我们才能完善能力建设,大家有能力去识别更有意义的,一些有价值,更深层次的一些问题,这样在评审过程中才能有的放矢。

我觉得,一上来就说能力建设,谈赋能,虽说不一定不行,但是效果很可能不太好,甚至就有反作用。

这就是从意愿到能力的曲折前进。共勉。