在代码合并之前，被提交的代码必须要至少一个人认可。代码评审的童鞋可以针对要合并的代码给出各种评论。有的是评论是询问，代码作者直接回复或者解释就可以；有的是指出代码的问题，代码作者可能会据此改动，也可能会不同意，那就需要回复评论，阐述观点，这样你来我往的对要提交的代码进行讨论，最终需要达成一致然后进行合并。
有些技术比较🐂的程序猿会说：“看到代码写的太差了，这样来回评论效率太低了，有那时间还不如我自己花十分钟搞定。”其实以前我也有过类似的想法，直到我成了老程序猿…..
首先，从对方的角度来讲，代码写的不好，可能是对业务不熟悉，对编程语言不熟悉，也可能是对公司代码的整体架构不熟悉，如果你帮他写，而不是耐心的指出问题，那么下一次他可能还是不知道怎么做，这样不仅无益于别人成长，有时候甚至会让别人有挫败感。并且，帮助别人写代码的方式可扩展性很差。即使代码审查会花掉十倍于你自己写的时间和精力，但它会让人明白代码应该怎么写，从长远来看，这其实是在一定程度上“复制”你的生产力。作为大牛的你不能什么都自己写，尤其是带项目带新人的大牛，每天审查5个人的代码和写5个人的代码，长期而言那个更合算呢？答案明显是前者。
代码审查初期会比较辛苦，不过效果会随之慢慢显现。慢慢的小组成员可以互相进行代码审查，代码质量也会进一步得到保障。写代码是一个学习的过程，怎么做一个好的代码审核人更是一个学习和成长的过程。自己绕过一个坑不难，难得是看到别人那么走，远远地你就能告诉他那里有个坑，而他在你的指导下以后也会帮忙指出别人类似的问题。
记住：帮助别人成长的同时，你和你的团队也在成长。