CodeReview的目的是提升代码质量，尽早发现潜在缺陷与BUG，降低修复成本，同时促进团队内部知识共享，帮助更多人更好地理解系统。
下面我们开始了解关于CodeReview的一些原则。
架构设计
1、单一职责原则：
一个类只能干一个事情，一个方法最好也只干一件事情。比较常见的违背是一个类既干UI的事情，又干逻辑的事情，这个在低质量的客户端代码里很常见。
2、行为是否统一：
例如：1)缓存是否统一。2)错误处理是否统一。3)错误提示是否统一。4)弹出框是否统一。
3、代码污染：
代码有没有对其他模块强耦合。
4、重复代码-->应该抽取。
5、开闭原则。
6、面向接口编程。
7、健壮性。
例如：1)是否考虑线程安全 2)数据访问是否一致性 3)边界处理是否完整 4)逻辑是否健壮 5)是否有内存泄漏 6)有没有循环依赖 7)有没有野指针 8)是否检查了数组的“越界“错误
8、错误处理。
9、改动是不是对代码的提升：新的改动是打补丁，让代码质量继续恶化，还是对代码质量做了修复
10、效率/性能：
例如：1)关键算法的时间复杂度多少？有没有可能有潜在的性能瓶颈 2)客户端程序对频繁消息和较大数据等耗时操作是否处理得当
代码风格
1、可读性：衡量可读性的可以有很好实践的标准，就是 Reviewer 能否非常容易的理解这个代码。如果不是，那意味着代码的可读性要进行改进
2、命名：例如：1)命名对可读性非常重要 2)是否跟系统属性命名造成冲突 3)英语用词尽量准确一点，必要时可以查字典。
3、函数长度/类长度：例如：1)函数太长的不好阅读 2)类太长了，检查是否违反的 单一职责 原则。
4、注释：恰到好处的注释,不是注释越多越好。
5、参数个数：不要太多，一般不要超过 3 个。
总结
在收到 PR 的时候，我关注的第一件事情是：「谁写的这段代码？TA 是初级工程师还是资深工程师？TA 是刚接触到这部分代码还是开发多年的老鸟？我以前是否 review 过 TA 的代码？我对这段代码所属的模块是否熟悉？」
当我 review 我熟悉的人的代码的时候，我十分清楚 TA 写这段代码的时候是怎么想的，并且我知道 TA 在写代码可能遇到什么问题。初级工程师的常常需要更多手把手的指导，比如为他们提供更多的样例代码和参考；资深工程师则需要提醒他们注意他们写的高性能和抽象的代码是很难阅读的，所以需要写更多的注释和文档。