一次因代码走查引发的思维碰撞

事情起因是这样的,我们团队践行每日代码走查(daily code review)已有超过一年了,走查过程中大家会针对前一天提交的代码提出不少问题和修改意见,然后由一位质量跟踪员将这些问题及问题的修改责任人,记录在wiki页面的表格里


作者:知猪侠_CD

团队今天的迭代回顾会,有一个小议题是关于“代码走查记录的问题关闭不及时”的问题。

事情起因是这样的,我们团队践行每日代码走查(daily code review)已有超过一年了,走查过程中大家会针对前一天提交的代码提出不少问题和修改意见,然后由一位质量跟踪员将这些问题及问题的修改责任人,记录在wiki页面的表格里。如果修改责任人下来将代码问题处理关闭了,就登陆wiki,对相关问题项的复选框打勾,表示问题已经被修复。

看起来,规则和人员都是明确的。但从近几个月观察来看,走查发现问题的修复和关闭情况却不甚理想,通常都有不少问题一直摆在那里,到了月底还没有打勾解决。我通常会扮演“看门人”的角色,在月底去跟催打勾,但坦率地讲效果不佳,而且事倍功半。

由于项目和部门质量部都会关注每个团队的代码走查执行落地情况,因此,虽然每天都花费了精力投入代码走查,但是外部观感和结果统计来看却是一堆问题没有及时关闭,问题没有闭环。

      这到底是哪个环节出了问题?谜题该怎么破?

看似小问题,大家你一言我一语,展开了一场别开生面的民主大讨论。

观点1:质量监督员的问题。

质量监督员不仅要记录,还要跟催相关的开发负责人及时修改,这样就不会遗留那么多问题到月底了。

赞同的小伙伴甲:质量跟踪员,没有很好地履行自己的职责——对了,大家知道本迭代的质量跟踪员是谁吗?算了,恐怕质量监督员自己都不知道,责任没有落实到人。

赞同的小伙伴乙:那我们就来看看迭代轮值表,下个迭代起,让跟踪员尽到责任——不妨把质量跟踪员的名字写个便签纸,贴在大屏幕旁边。

反对的小伙伴丙:这不是质量跟踪员的问题,而是个人的主动性和意识问题。假设按这种方案,质量跟踪员既要记录,又要去跟催别人修改,一次催了不行,还要催二次,质量跟踪员好心累。不妨看看,每次都是哪几个人没有改?

持中立态度的小伙伴丁:每个人都是聪明的,有自己的做事方式,要信任其专业性。不要把大家弄得针尖对麦芒,太有压力。

观点2:不是质量跟踪员的问题,而是写代码的人的问题。

赞同的小伙伴甲:谁制造的问题,谁负责清理,应该有主动性。明明是你的问题,为什么要质量跟踪员来买单?

赞同的小伙伴乙:我自己就是走查的问题下来立即就修改了。今日事,今日毕,既然认可走查的记录,写代码的同学就应该解决掉问题。

反对的小伙伴丙:首先,我不认可记录的所有问题,比如:变量命名,类名单词拼写错误,从继承关系改为组合关系,这些是不是一定要改,不改会不会有问题?记录到wiki的问题,是否经过了当事人认可,或者说多数人当场同意。

其次,有一类问题,属于研讨类问题,并不是要修改代码,现在也记录了。适不适合记录在代码走查的wiki里?这些问题,比较耗时,一时半会也关闭不了。通常是重要不紧急。

回答小伙伴丙的丁同学:两点建议非常好。记录的内容,应该是大家认可的,有疑问的最好走查当场确认后再记录。非代码类问题,衍生出来的业务澄清或者业务研讨,最好另外用本子记录,这样就不会和代码修改的问题混为一谈了。

观点3:都不对,是当前的做法有问题

小伙伴甲:不如就不要质量跟踪员记录了,走查时让写代码的同学自己讲,自己记录。自己记录的问题自己肯定是已认可的,肯定会去修改。

小伙伴乙:频繁轮换不太好吧,而且讲解的人需要专注,不建议一边讲解一边记录。不如不要轮换质量跟踪员,统一我来记录吧,保证月底前都会打勾。

小伙伴丙:阿弥陀佛,老衲实在看不下去了……那么小的事情,怎么就越搞越复杂呢?

小伙伴丁:只要涉及到人的事,就没有小事。因为人与人的认知,行为,习惯都不同。除了每个人的心智模式的差异,还有人与人之间的关系,群体的复杂性。如果只用“我”的视角来看问题,难免难以理解这背后的复杂性。遇到问题,要用更多的视角去看待问题,分析问题。不用着急得出结论。

小伙伴丙:是滴,就事论事,大家激烈讨论完,依然还是好伙伴。

未划休止符的结论

虽然,这个问题在求同存异后,还没有得到普遍认可的结论。但我觉得,能开放式地探讨挺好的,不至于陷入个体思维局限。正如乔帮主说的,keep hungry, stay foolish。观点没有对错,而是说是否适合和贴近团队的实际情况。

秉持敏捷精神,我们可以拥抱变化,尝试一下大家头脑风暴后提到的几种小改进,然后看看效果,好的就保留,不好则再微调。

阅读余下内容

发表评论

电子邮件地址不会被公开。 必填项已用*标注


京ICP备12002735号