代码评审

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

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

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