一、目的
Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们
可以对代码、测试过程和注释进行检查。
Code Review主要用来在软件工程过程中改进代码质量，通过Code Review可以达到
如下目的：
1) 在项目早期就能够发现代码中的bug，将bug扼杀在摇篮中。
2) 帮助初级开发人员学习高级开发人员的经验，达到知识共享。
3) 避免开发人员犯一些很常见，很普通的错误。
4) 保证项目组人员的良好沟通。
5) 项目或产品的代码更容易维护。
6) 提升代码质量，提高团队开发效率。
二、评审条件
1、大型项目，增加/修改超过10个文件或超过500行代码的，需组织CodeReview会议，邀请相关同事及高阶同事参与代码Review
2、小型项目，小需求修改（少于10个文件变更或少于500行代码的），至少需要1~2位同事帮忙进行代码Review并提出点评建议
3、重点逻辑，建议找相关同事共同Review一下
代码评审的先决条件：代码已通过Alibaba Java Coding Guidelines(idea 插件）进行代码检查。
三、评审范围
代码的一致性、编码风格、代码的安全问题、脱敏问题、代码冗余、是否正确设计以符
合设计要求(性能、功能)与设计文档相同等。
完整性检查（功能点、业务日志、异常日志等）
一致性检查（代码逻辑是否符合设计文档，代码风格是否统一等）
正确性检查（编码规范，注释准确，变量定义和使用等）
可修改性检查（如字典值123，使用专门的常量类等）
可预测性检查（死循环、无穷递归、数组越界、空指针等）
可理解性检查（命名规则、注释是否清晰、gitlab修订记录描述清晰等）
代码逻辑检查（如实现过于复杂、代码可读性、扩展性等）
PS：优先级从上到下
命名规范遵循：
命名规范遵循：《项目命名规范》
接口规范遵循：《RestfulL API规范》
日志规范遵循：《异常日志》
数据库开发规范遵循：《MYSQL数据库涉及规范》
前端规范遵循： 《WEB端编码规范》
五、评审人员
必须有该项目组下相关研发人员，至少2名参与；另外需邀请架构部1位同事协同评审。
多人参与可以形成意见的挑战，讨论，趋于大同标准化老员工参与，可以帮助发现隐藏的需要注意的事项。
六、评审时间
Code Review由项目负责人发起，一个项目过程中至少2-3次，主要集中在项目中后期，如果项目规模较大，功能较多，时间比较宽裕，也可适当增加。
PS：代码评审不需要太正式，时间不宜太长，建议控制在30分钟以内。
注意：代码评审必须在在项目提测时间前后一两天完成，万不可等到测试之后再来评审。
七、评审工具
研发协作平台; IDEA等开发工具
