什么是CodeReview
CodeReview的目的是提升代码质量，尽早发现潜在缺陷与BUG，降低修复成本，同时促进团队内部知识共享，帮助更多人更好地理解系统。
如何进行CodeReview
如果使用Object-C进行开发，CodeReview分为两个阶段：本地 Review、远端 Review
本地Review
使用OCLint来进行本地走查，关于其安装和使用，参考文章： OCLint 代码静态分析 自动化 Code Review OCLint 安装与使用 OCLint 规则与结果分析
远端Review
远端 Review 和 本地 Review 大体相似，区别在与引用构建的脚本的对象从 Xcode 变成了 Jenkins CI ，报告的展示者从 Xcode 变成了 SonarQube 。 具体流程也在自动化 Code Review文章中可以找到。 以上过程可以说还是在自我检查阶段。
团队协作时的CodeReview
在团队（尤其是大规模团队）协作中，一般需要有人工Review的过程，如使用gitflow或其他协作工具，代码提交更新时，需要先经过CodeReview，通过后才允许合并，参考文章： 从零开始Code Review Git 在团队中的最佳实践--如何正确使用Git Flow
关于CodeReview的一些原则
架构/设计/常规
1.单一职责原则
一个类只能干一个事情，一个方法最好也只干一件事情。比较常见的违背是一个类既干UI的事情，又干逻辑的事情，这个在低质量的客户端代码里很常见。
2.行为是否统一
例如： 1)缓存是否统一 2)错误处理是否统一 3)错误提示是否统一 4)弹出框是否统一 5)……
3.代码污染
代码有没有对其他模块强耦合
4.重复代码-->应该抽取
5.开闭原则
6.面向接口编程
7.健壮性
1)是否考虑线程安全 2)数据访问是否一致性 3)边界处理是否完整 4)逻辑是否健壮 5)是否有内存泄漏 6)有没有循环依赖 7)有没有野指针 8)是否检查了数组的“越界“错误 9)……
8.错误处理
9.改动是不是对代码的提升
新的改动是打补丁，让代码质量继续恶化，还是对代码质量做了修复
10.效率/性能
1)关键算法的时间复杂度多少？有没有可能有潜在的性能瓶颈 2)客户端程序对频繁消息和较大数据等耗时操作是否处理得当
代码风格
1.可读性
衡量可读性的可以有很好实践的标准，就是 Reviewer 能否非常容易的理解这个代码。如果不是，那意味着代码的可读性要进行改进
2.命名
1)命名对可读性非常重要 2)是否跟系统属性命名造成冲突 3)英语用词尽量准确一点，必要时可以查字典
3.函数长度/类长度
1)函数太长的不好阅读 2)类太长了，检查是否违反的 单一职责 原则
4.注释
恰到好处的注释,不是注释越多越好
5.参数个数
不要太多，一般不要超过 3 个
作者：忠橙_g 链接：https://www.jianshu.com/p/4b382cc95850
