走查问题引发的讨论“大作战”【格智】

meimei

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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