代码审查：究竟是好主意还是坏主意？

代码审查在软件开发中是老生常谈的话题。很多人都认为代码审查的花销大而且又耗时，特别是当大家忙完软件项目又把它送去软件测试部门时，对一些开发人员来说，它更会引发更多的办公室政治和流言蜚语。

一次代码审查可能会使代码逐渐得到改进，如果你认为从有效的代码审查中只是稍微改进了一下软件那就错了。开发人员若得知他们的代码会被评估会更加努力工作。因此，代码审查有利于导师制度，程序员们会学到更多，代码审查还能激发团队凝聚力。

代码审查优点：

在老板看来，代码审查是个不错的好方法，某些部门甚至将同行代码审查作为主要进程中的一部分。

1. 代码审查能够帮你查找Bug以及发现错误；
2. 开发者们分享各自领域里的知识有助于提升质量标准；
3. 代码审查提供指导与学习；
4. 加强团队建设的能力。

既然有如此多的优点，那为何会有不少开发者拒绝做代码审查呢？文化问题或许已成为一种巨大的障碍，大部分开发者会厌恶代码审查是因为他们无法忘记那些痛苦的审查会议，更槽糕的是，他们害怕因劣质代码而遭到管理者的批评与指责。

代码审查缺点：

1. 代码审查也可能导致团队之间相互怨恨、内部分裂；
2. 审查者提供代码虚假信息；
3. 开发者们宣称个人的编码标准；
4. 代码审查是个苦差事，会破坏上下级之间的关系。

也许代码审查最大障碍是恐惧，开发者担心错过最后期限，害怕分心，害怕投入过多时间。

对于任何既定的团队，代码审查的有效性介于两者之间——友好的银弹或者团队的杀手锏。当然，这还取决于你的团队是否愿意积极拥抱代码审查工作，任何一款开发工具，仅使用它还是不够的，前提是你必须确保以正确的方式在使用。这里作者将分享高效代码审查的十个经验：1.代码审查要求团队有良好的文化；2.谨慎的使用审查中问题的发现率作为考评标准；3.控制每次审查的代码数量；4.带着问题去进行审查；5.所有的问题和修改，必须由原作者进行确认；6.利用代码审查激活个体“能动性”；7.在非正式，轻松的环境下进行代码审查；8.提交代码前自我审查，添加对代码的说明；9.实现中记录笔记可以很好的提高问题发现率；10.使用好的工具进行轻量级的代码审查。

经过几番讨论与思考，我认为代码审查成功的关键要素在于信任和培训。主要体现在：

• 团队成员必须坚信，代码审查的反馈并不是人身攻击或者怀疑开发者的能力；
• 审查者要相信，如果提供改进建议，被审查者不会痛恨他们；
• 团队应该把查看代码审查当做建设性的反馈意见，而不是给队友进行分级或是批评。

当然，不可避免的是，团队中也不完全存在信任感。倘若有了正确的代码审查培训就可以帮助建立团队间的相互信任。现在你也可以给其他人进行代码审查，在代码审查时留下备注信息；指导新的开发者如何给予适当的反馈意见，比如向有经验的开发者学习，他们可以提供更多有价值的信息；团队领导者从审查中进行备份并不断完善加强团队间的信任与尊重。

总结：

我认为，代码审查更重要的是一种技术分享或者代码共享。在审查过程中，通过被审查者的讲解、审查人员的质询来发现问题并传播知识。如果认真审查过代码至少可以让审查者在一定程度上知道自己的同时在做什么、做的怎么样，而且，如果审查者做过相关东西并且有更好的解决方案，能够提出来也可以做到一定的技术分享。同时被审查者如果被审查问题较多，也可以在一定程度上提高对技术的追求。