通常在大一点的企业中,会定期面对面对代码进行评审
Code Review 的意识
- 作为一个 Developer ,不仅要提交可工作代码(Deliver working code),更要提交 可维护的代码(Deliver maintainable code)
- 必要时进行重构,随着项目的迭代,在开发新增功能的同时,开发要主动计划重构的工作项
- 开放的心态,虚心接受大家的评审建议(Review comments)
代码评审的方式
- 开 Code Review 会议
- 团队内部会整理 Check List
- 团队内部成员交换代码
- 找出可优化方案
- 多问问题,例如:“这块怎么工作的”,“如果碰到怎么怎么情况,这会怎么处理的”
- 区分重点,优先抓住 设计、可读性、健壮性等重点问题
- 整理好的编码实践,用来作为 Code Review 的参考
评审内容
架构/设计
- 单一职责原则
- 这是经常被违背的原则,一个类只能干一个事情,一个方法最好也只干一件事情。比较常见的违背是,一个类既干UI的事情,又处理逻辑的事情,这个在低质量客户端代码里特别常见。
- 行为是否统一,例如:
- 缓存是否统一
- 错误处理是否统一
- 错误提示是否统一
- 弹出框是否统一
- ……
- 代码污染
- 代码有没有对其他模块强耦合
- 重复代码
- 开闭原则
- 面向接口编程
- 健壮性
- 是否考虑线程安全
- 数据访问是否一致性
- 边界处理是否完整
- 逻辑是否健壮
- 是否有内存泄漏
- 有没有循环依赖
- 有没有野指针
- ……
- 错误处理
- 改动是不是对代码的提升
- 新的改动是打补丁,让代码质量继续恶化,还是对代码质量进行优化
- 效率/性能
- 关键算法的时间复杂度多少?有没有可能存在潜在的性能瓶颈
- 客户端程序对频繁消息和交大数据等耗时操作是否处理得当
代码风格
- 可读性
- 衡量可读性有一个很好的实践标准,就是Reviewer能否非常容易的理解这个代码。如果不是,那意味着代码在可读性方面需要进行改进
- 命名
- 命名对可读性非常重要,英语用词尽量准确,不确定就查字典去。
- 函数长度/类长度
- 函数长度不宜太长,太长的不宜阅读
- 类长度太长的,检查是否违反了 单一职责 的原则
- 注释
- 恰到好处的注释
- 参数个数
- 不要太多,一般最好不超过3个
Review your own code first
- 每次提交评审前,先自己整体把代码过一遍,尤其是要注意看看自己有没有犯什么低级错误,要是被别人看到指出来,挺丢脸的。