团队今天的迭代回顾会，有一个小议题是关于“代码走查记录的问题关闭不及时”的问题。
事情起因是这样的，我们团队践行每日代码走查(daily code review)已有超过一年了，走查过程中大家会针对前一天提交的代码提出不少问题和修改意见，然后由一位质量跟踪员将这些问题及问题的修改责任人，记录在wiki页面的表格里。如果修改责任人下来将代码问题处理关闭了，就登陆wiki，对相关问题项的复选框打勾，表示问题已经被修复。
看起来，规则和人员都是明确的。但从近几个月观察来看，走查发现问题的修复和关闭情况却不甚理想，通常都有不少问题一直摆在那里，到了月底还没有打勾解决。我通常会扮演“看门人”的角色，在月底去跟催打勾，但坦率地讲效果不佳，而且事倍功半。
由于项目和部门质量部都会关注每个团队的代码走查执行落地情况，因此，虽然每天都花费了精力投入代码走查，但是外部观感和结果统计来看却是一堆问题没有及时关闭，问题没有闭环。
这到底是哪个环节出了问题?谜题该怎么破?
看似小问题，大家你一言我一语，展开了一场别开生面的民主大讨论。
观点1：质量监督员的问题。
质量监督员不仅要记录，还要跟催相关的开发负责人及时修改，这样就不会遗留那么多问题到月底了。
赞同的小伙伴甲：质量跟踪员，没有很好地履行自己的职责——对了，大家知道本迭代的质量跟踪员是谁吗?算了，恐怕质量监督员自己都不知道，责任没有落实到人。
赞同的小伙伴乙：那我们就来看看迭代轮值表，下个迭代起，让跟踪员尽到责任——不妨把质量跟踪员的名字写个便签纸，贴在大屏幕旁边。
反对的小伙伴丙：这不是质量跟踪员的问题，而是个人的主动性和意识问题。假设按这种方案，质量跟踪员既要记录，又要去跟催别人修改，一次催了不行，还要催二次，质量跟踪员好心累。不妨看看，每次都是哪几个人没有改?
持中立态度的小伙伴丁：每个人都是聪明的，有自己的做事方式，要信任其专业性。不要把大家弄得针尖对麦芒，太有压力。
观点2：不是质量跟踪员的问题，而是写代码的人的问题。
赞同的小伙伴甲：谁制造的问题，谁负责清理，应该有主动性。明明是你的问题，为什么要质量跟踪员来买单?
赞同的小伙伴乙：我自己就是走查的问题下来立即就修改了。今日事，今日毕，既然认可走查的记录，写代码的同学就应该解决掉问题。
反对的小伙伴丙：首先，我不认可记录的所有问题，比如：变量命名，类名单词拼写错误，从继承关系改为组合关系，这些是不是一定要改，不改会不会有问题?记录到wiki的问题，是否经过了当事人认可，或者说多数人当场同意。
其次，有一类问题，属于研讨类问题，并不是要修改代码，现在也记录了。适不适合记录在代码走查的wiki里?这些问题，比较耗时，一时半会也关闭不了。通常是重要不紧急。
回答小伙伴丙的丁同学：两点建议非常好。记录的内容，应该是大家认可的，有疑问的***走查当场确认后再记录。非代码类问题，衍生出来的业务澄清或者业务研讨，***另外用本子记录，这样就不会和代码修改的问题混为一谈了。
观点3：都不对，是当前的做法有问题
小伙伴甲：不如就不要质量跟踪员记录了，走查时让写代码的同学自己讲，自己记录。自己记录的问题自己肯定是已认可的，肯定会去修改。
小伙伴乙：频繁轮换不太好吧，而且讲解的人需要专注，不建议一边讲解一边记录。不如不要轮换质量跟踪员，统一我来记录吧，保证月底前都会打勾。
小伙伴丙：阿弥陀佛，老衲实在看不下去了……那么小的事情，怎么就越搞越复杂呢?
小伙伴丁：只要涉及到人的事，就没有小事。因为人与人的认知，行为，习惯都不同。除了每个人的心智模式的差异，还有人与人之间的关系，群体的复杂性。如果只用“我”的视角来看问题，难免难以理解这背后的复杂性。遇到问题，要用更多的视角去看待问题，分析问题。不用着急得出结论。
小伙伴丙：是滴，就事论事，大家激烈讨论完，依然还是好伙伴。
未划休止符的结论
虽然，这个问题在求同存异后，还没有得到普遍认可的结论。但我觉得，能开放式地探讨挺好的，不至于陷入个体思维局限。正如乔帮主说的，keep hungry, stay foolish。观点没有对错，而是说是否适合和贴近团队的实际情况。
秉持敏捷精神，我们可以拥抱变化，尝试一下大家头脑风暴后提到的几种小改进，然后看看效果，好的就保留，不好则再微调。
