谈CODE REVIEW

上午我所在的项目组花了半个小时的时间完成了一个人的code review，两天的量，因为昨天也没有review。也就是说还有五个人的code没有给到大家去review。

影响是啥呢？代码坏味道的堆积。今天只review了一个人的，明天可能也只是一个人的，情况好一点是把这个人昨天的也能看完。那么到明天的这个时候实际上是9个人天的code没有被review到，仅仅只算这两天的，以前的还没算进去。其实已经失去及时改进的机会。效果不佳。当代码堆积，一直在review以前的代码时，人们的记忆有点模糊的，可能还要思考一会才知道为啥这么写，review时间本身就不够，回忆还要花掉一部分，效率明显不高。knowledge没有及时共享，记得前几天和pair做卡。push代码的时候发现有些重复了，如果提前知道这件事一定会去confirm，而不是还要再做一遍。另外一方面一些好的方法手段以及遇到的挑战没有及时告知给团队，也许其他人就不会花同样多的时间去做研究。有可能影响测试。当我们check完之后再去review代码，去做重构工作，新提交的代码并不能百分之百地保证对功能没有一丝一毫的影响，假设那时候相应的功能已经测完了，新的改动理论上应该要回归的，同时也加大的测试的工作量，如果及时review及时重构基本上就能保证代码的质量在团队的所有开发人员这里是过关了的。

造成这种现象的原因很多。比如下午的各种各样的会的冲突，比如没有一个regular的时间，每次想订的时间会议室unavailable，其实反而有一个好处，当没有会议室的时候我们会选择站着review，效率相对会快很多，坐着的时候都不想动弹，就想一直那么讨论下去。即便retro上提过这个regular的review，也会因为要showcase继续往后推。实际上有后悔没有强行建议去review，即便是showcase也不应该影响review的。半个小时的时间能怎么影响showcase啊。当然重要的是还没有成熟稳定下来。

写到这里我想到需要一个owner每天到点喊大家review，每次不是我就是我们tech lead，忙的时候就没人喊了。不管有没有谁在开会，不管是否缺少了一两个dev，review照常进行，没讲的下次一并讲了。继续解决的代码坏味道堆积的问题就需要跟大家强调这周必须要赶上应有的进度了。迭代刚开始，有一定的时间去做这事。

code review在交付团队中是非常重要的环节，也是一个所有开发聚在一起讨论技术细节的非常好的机会。我一直push在团队中有一个完善的review的机制，同时我自己也矛盾，因为更想关注前端技术栈，那些看着没有感觉的后端代码着实没啥吸引力。苦于项目前端力量薄弱，也是无奈。