Code Review关注点

Review可分为3个级别，高一级会包含低一级的内容。

一、初级，规范级

不熟悉相关代码，只能review是否遵守规范，以可读性为主。规范按照【语言>框架>系统平台>项目>公司>跟上下文相同】的优先级来遵守。关注点：

1. 代码规范，命名：<变量|常量|函数|类|文件|目录>名的<大小写|缩写|减号或下划线>等
2. 代码规范，格式：换行、空行、空格、tab或空格数、include/import排序等
3. 代码规范，内容：注释、函数体行数限制、异常处理、不留僵尸代码、没有幻数、是否使用Lamda表达式等
4. 代码规范，位置：目录、包或命名空间层次等
5. 使用规范，内部约定：是否【统一用了或不能用】特定函数、接口、库。比如日志都通过封装类来打印
6. 提交规范：commit log是否符合规范；是否不同任务（需求或bugfix）分开提交，是否同一个任务合并提交
7. 分支规范：是否提交在正确的分支，例如版本。还有额外的要求，例如提测后不提交跟修复bug无关的代码，去下一个版本或临时分支提交。
8. review流程规范：是否给正确的人review、抄送到位、按意见修改等
9. 设计规范：遵守基本的设计原则，每个类职责简单清晰，解耦。
10. 文档规范：复杂度高的话是否有必要写文档，实现和文档是否一致。

二、中级，性能架构级

熟悉相关代码但不熟悉需求，可更多关注技术设计，看重性能、可扩展性、可维护性、安全性、稳定性等。关注点：

1. 跨模块/应用/端交互，设计是否合理，有没有引入耦合
2. 设计原则和设计模式的应用
3. 异步和原子性问题：Timer、跨线程、跨进程、锁
4. 性能：IO时长，是否需要后台线程执行，是否有冗余操作，lazy load，SQL优化、算法复杂度等。
5. 日志、埋点合理，异常情况的原因通过日志可查，也不滥用。
6. 安全考虑：加密、检验等
7. 重大异常有UI提示，便于用户帮忙定位问题。（这种场景不能靠产品来提出）
8. 可扩展性：是否足够灵活地应对变化
9. 是否会产生野指针或内存常驻对象

三、高级，需求级

又熟代码又熟需求，会关注更多细节，一般结对编程才会做到这个程度。关注点：

1. UI：文案、大小、颜色、阴影、字体、对齐方式、前后层次、动画、图片、声音、视频等，不同状态下还可能不一样
2. 功能与流程逻辑：出入口、状态与条件、规则（类型、精度、取值范围、默认值、显示格式、计算处理方式等）、异常情况（要知道概率和源头原因）。
3. Bugfix，是否真的能解决bug。