如何进行高效的代码评审
代码评审有很多用途，最常见的是在代码发布之前检查缺陷，除此之外，代码评审还可以用来传播知识、保证质量。最简单的代码评审是在变更提交之前对代码进行快速浏览，以批准分支合并；最详细的代码评审，可能包括配对、逐行评审，以及多轮评审和反馈。
如果你评审的代码短小、且有清晰的描述，那恭喜你有个好的开始；即便如此，刚开始时，很多人还是会觉得无从下手。这篇文章主要介绍如何在团队中开展代码评审，相信对刚刚接触此项工作的同学会有帮助。
一、拆分
如果需要评审的代码量太大（成百上千行），需要先拆分成容易处理的多个部分。如果代码不好拆分，或者拆分后代码量依然很大，就需要跟原作者一起工作。这有点儿类似于结对开发，作者和评审者仿佛在道路两侧并肩前行，作者介绍代码，评审者提出问题；当穿行过整个代码后，在代码行中批注出当时讨论的问题和结论。
二、执行评审
1、进行多轮评审
在评审过程中要记住所有需要检查的事项很困难，频繁切换评审语境也会带来问题。比如，你正专注于代码可读性评审时，可能就遗漏了安全性和性能方面的问题。好的处理方式是代码评审做多轮，每轮只针对一个主题，这个主题结束后，就提交评审报告，再开始下一个主题。评审检查项的顺序应该从大到小，从一般到特殊；比如说，如果整个类（方法）都需要重构，那再去提修改变量命名的建议就没什么意义。
必须毫不犹豫的进行多论代码评审，并在此过程中不断扩充评审范围。
2、评审项
（1）需求满足程度。
代码满足需求没有？
UI实现跟设计是否一致？
变化是否在允许范围内？
（2）架构和设计
功能是如何实现的，能否从代码中比较清晰的识别出设计？
设计是否遵从一贯的准则，如果没有，新的变化是否有意义？
是否足够简洁，还是进行了过度设计？
是否支持扩展，是通用的还是专用的，是否过早进行了抽象？
如果明天新来一个同学，从代码中能理解设计不？
（3）副作用
对于复杂的应用来说，看似无害的改动可能会影响核心功能。
代码会不会给其他模块带来不可预料的后果？
如果一个方法被修改了，是否所有的调用者都进行了更新？
增加的外在依赖是否经过评估？
（4）测试覆盖
进行测试了么？
测试脚本未来会不起作用么？
测试了正确的方法么？
测试架构是合适的么？
边缘测试做了么？
（5）性能
是否会有性能瓶颈？
做了哪些查询，是否比需要拿了更多的数据？
这些代码会不会对其他模块的性能产生影响？
（6）可读性和编码风格
不用作者解释，你能读懂代码么？
没有作者的帮助，你能调试和修改代码么？
变量的用途是否能从名字上看出来？方法和类呢？
（7）日志记录
如果没有良好的日志，几乎不可能正确地调试服务器代码。是否所有东西都正确地记录或追踪？
（8）异常处理
后端异常是如何处理的；它们是如何与用户沟通的；反馈是否在可能情况下激活？
三、致力于传递价值
所有的代码评审都为了传递价值，用来帮助团队提高交付质量，而不是陷入细节的争论。评审过程中要注意阻止代码提交的分寸，如果有错误，明确不可提交；如果需要重构，则跟作者沟通时间，看当前重构还是留待以后。不要幻想完美主义，完美是不存在的，只要代码没有错误且比前一版本更好，就应该通过评审。
（1）要有帮助
代码评审的目标不是为了阻止缺陷，那是测试要做的工作。代码评审是团队在代码库中学习的机会，也是提高代码质量的机会。坚持进行有效的代码评审，每个人都会从中收获良多。代码评审中最有效的传授经验的方式，就是写下详细的评论信息，必要时链接到有助于理解的文章。不要仅仅指出问题，应该说明为什么有问题，如何改进问题。如果有更高效的查询方法，应该在备注中介绍这种方法，而不仅仅指出问题。
（2）要人性化
代码评审的核心是要向作者反馈问题，这可能会是个艰难的工作。团队中的每个人都希望尽力做到最好，因此反馈问题的方式要特别谨慎，要注意方式方法。不要忘记在评审中对好的代码进行充分肯定。
四、最佳实践
明白代码评审时的目标（检查项）
在评审之前完成构建和单元测试工作
一次评审不要超过60分钟
一次评审的代码量不要超过400行
在反馈中给出具体的解决办法而不是只提示问题
在团队中传递代码评审的目标和期望
在代码评审的过程中要包含团队中的每一个人
培养积极的文化
使用自动化工具提高效率
