技术沙龙 | 8月25日与多位资深技术大咖讨论小顺序电商实战

团队明天的迭代回忆会，有一个小议题是关于“代码走查记载的成绩封锁不及时”的成绩。

事情原因是这样的，我们团队践行每日代码走查(daily code review)已有超过一年了，走查进程中大家会针对前一天提交的代码提出不少成绩和修正意见，然后由一位质量跟踪员将这些成绩及成绩的修正责任人，记载在wiki页面的表格里。假设修正责任人上去将代码成绩处置封锁了，就登陆wiki，对相关成绩项的复选框打勾，表示成绩曾经被修复。

看起来，规则和人员都是明白的。但从近几个月察看来看，走查发现成绩的修复和封锁状况却不甚理想，通常都有不少成绩不断摆在那里，到了月底还没有打勾处置。我通常会扮演“看门人”的角色，在月底去跟催打勾，但坦率地讲效果不佳，而且事半功倍。

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

这究竟是哪个环节出了成绩?谜题该怎样破?

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

观念1：质量监视员的成绩。

质量监视员不只要记载，还要跟催相关的开发担任人及时修正，这样就不会遗留那么多成绩到月底了。

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

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

支持的小同伴丙：这不是质量跟踪员的成绩，而是团体的自动性和看法成绩。假定按这种方案，质量跟踪员既要记载，又要去跟催别人修正，一次催了不行，还要催二次，质量跟踪员好意累。不妨看看，每次都是哪几团体没有改?

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

观念2：不是质量跟踪员的成绩，而是写代码的人的成绩。

赞同的小同伴甲：谁制造的成绩，谁担任清算，应该有自动性。明明是你的成绩，为什么要质量跟踪员来买单?

赞同的小同伴乙：我本人就是走查的成绩上去立刻就修正了。昔日事，昔日毕，既然认可走查的记载，写代码的同窗就应该处置掉成绩。

支持的小同伴丙：首先，我不认可记载的一切成绩，比如：变量命名，类名单词拼写错误，从承袭关系改为组合关系，这些是不是一定要改，不改会不会有成绩?记载到wiki的成绩，能否经过了当事人认可，或许说少数人当场赞同。

其次，有一类成绩，属于研讨类成绩，并不是要修正代码，如今也记载了。适不适宜记载在代码走查的wiki里?这些成绩，比较耗时，一时半会也封锁不了。通常是重要不紧急。

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

观念3：都不对，是以后的做法有成绩

小同伴甲：不如就不要质量跟踪员记载了，走查时让写代码的同窗本人讲，本人记载。本人记载的成绩本人一定是已认可的，一定会去修正。

小同伴乙：频繁轮换不太好吧，而且解说的人需求专注，不建议一边解说一边记载。不如不要轮换质量跟踪员，一致我来记载吧，保证月底前都会打勾。

小同伴丙：阿弥陀佛，老衲真实看不下去了……那么小的事情，怎样就越搞越复杂呢?

小同伴丁：只需触及到人的事，就没有大事。由于人与人的认知，行为，习气都不同。除了每团体的心智形式的差异，还有人与人之间的关系，群体的复杂性。假设只用“我”的视角来看成绩，难免难以了解这背后的复杂性。遇到成绩，要用更多的视角去看待成绩，剖析成绩。不用着急得出结论。

小同伴丙：是滴，避实就虚，大家剧烈讨论完，依然还是好同伴。

未划休止符的结论

虽然，这个成绩在求同存异后，还没有失掉普遍认可的结论。但我觉得，能开放式地讨论挺好的，不至于堕入集体思想局限。正如乔帮主说的，keep hungry, stay foolish。观念没有对错，而是说能否适宜和贴近团队的实践状况。

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

【编辑引荐】

雷军22年前写的代码 你见过吗？

2018开源代码安全报告：每个代码库平均包含64个破绽

凶猛了！用不到20行的Python代码构建一个对象检测模型

女神把微信音讯撤回后好慌，Python几十行代码轻松查看撤回音讯！

2分钟编程技巧：不要在代码中运用循环

(责任编辑：admin)