代码评审

通常在大一点的企业中，会定期面对面对代码进行评审

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

• 每次提交评审前，先自己整体把代码过一遍，尤其是要注意看看自己有没有犯什么低级错误，要是被别人看到指出来，挺丢脸的。