为什么需要代码评审

保持统一的编码风格，是为了提高项目的代码质量。不说三五人的开发团队，即使是一个人单独负责项目开发，在单纯使用 Xcode 编码的情况下，也很难保证编码风格的一致性，因此需要代码评审的介入。代码评审包括两部分：自动化评审和人工评审。

提示：具体工具部署和使用，见后面的系列文章。

为什么把自动化评审放在前面？因为没有自动化评审，人工评审在编码风格统一方面能起到的成效微乎其微。（接受反驳~）

作为一名 iOS 开发工程师，经常会被苹果公司设计的开发框架折服，在 API 易用性方面绝对甩安卓开发几条街，但是在代码管理这块，却又是完全相反的结果。Xcode 作为主要编码工具，实在过于厚重，缺少很多实用编辑功能的同时，还对插件扩展进行了极大的限制。（最新的 Xcode10 提供了官方插件下载，不知未来这一现象是否会有所改善。）

提到扩展插件，是因为 Xcode 作为 iOS 开发的一等公民，本身未提供代码审查相关的功能，同时又没有赋予扩展插件足够的权限来实现完整的代码评审功能。（或许有？）

OC 的自动化评审

因工作相关，这里只介绍 OC 相关的自动化评审，swfit 流仅供参考。

本文介绍的自动化评审包括以下三个部分：

本地自动格式化工具
本地 Review 工具
远端 Review 工具

本地自动格式化工具

OC 代码格式化工具原先有不少，包括两个 Xcode 插件：ClangFormat 和 XcodeClangFormat，这里不对插件功能展开介绍了，因为相关工具在每次 Xcode 更新的时候，或多或少都会有兼容问题，而且目前也不满足我们项目开发的需求了，有兴趣的朋友们可以自行了解。

在这部分，我们需要工具具备以下能力：

不影响开发过程
提交代码之前，检测代码风格
默认拒绝提交不符合风格规范的代码
允许强制提交不符合风格规范的代码（容错）
无感提交符合风格规范的代码
能快速格式化不符合风格规范的代码
支持自定义代码风格，包括简单配置和深度扩展
支持忽略格式化指定目录、文件、代码段

照着需求找轮子，找不到就自己造一个。调研了几款代码格式化工具，最后决定使用 SpaceCommander 来实现本地代码格式化功能，看 spacecommander 项目的最近修改时间，可以知道作者很久没有维护了，但是并不影响使用，修修补补还是能跑的。

本地 Review 工具

格式化工具不是万能的，如对注释语句周边的代码进行格式化，可能会导致编译失败，甚至是隐藏bug。在保证代码不会被错误格式化的前提下，自动格式化工具需要避免对一些代码进行格式化操作。此时，就需要另外的工具来提示我们的小伙伴，哪些代码可以更优秀。

目前 OC 相关的 Review 工具主要包括 OCLint、Faux Pas、Infer 和 Clang Static Analyzer。

OCLint 是一个静态分析工具，可用于分析 C/C++/OC 代码，可以扫描出隐藏bug、未使用代码、复杂代码、坏味道的代码等。
Faux Pas 是收费产品，笔者没有深入研究。
Infer 是 Facebook 开源的静态分析工具，目前能检测出空指针访问、资源泄露以及内存泄露，可对C、Java和Objective-C代码进行检测。
Clang Static Analyzer 就是 Xcode 自带的源码分析工具，可以检测出一些问题，但是不够用，而且扩展性不佳。

自动化 Code Review 初期，笔者选择 OCLint 和 Clang Static Analyzer 作为主要的检测工具，运行一段时间看看成果，如果有需要再考虑接入 Infer。

远端 Review 工具

远端 Review 工具的基础还是 OCLint，区别在于驱动 OCLint 的对象从 Xcode 变成了 Jenkins CI，报告从本地展示变成了网页展示，同时记录下代码质量的演变历史。这套工具既能帮助开发写出更高质量的代码，也能在管理人员对工程质量的评估时，提供一个切面的数据支持。

这里使用到的工具包括 OCLint、Jenkins CI、Jenkins 插件 PMD，其实 PMD 已经属于过期插件，后期可能不再维护，往后可以迁移到 SonarQube + sonar-objective-c，后一方案应该更优秀，但是部署流程比较麻烦，笔者第一次运行以失败结束，决定先采用简单的 PMD 运行，若项目组能坚持进行 Code Review，再升级到 SonarQube。

小结

工具仅辅助，输出靠个人。

系列文章

OC团队编码规范化(1)
OC团队编码规范化(2) - 代码格式化
 OC团队编码规范化(3) - OCLint
OC团队编码规范化(4) - Jenkins & PMD