iOS开发：Code Review 指南

杏仁医生 iOS 端 Code Review 指南。

转载注明出处

指南不仅针对 Review 者，提交代码前，自己也应该按照步骤进行检查，避免低级错误和无用的反工。

我们按照以下步骤来进行 Code Review，来保证代码质量。

Merge Request

Code Review 的第一步是检查 Merge Request 是否符合规范。提交者应该保证 MR 的清晰：

• MR 标题说明改动的模块和改动内容，如果是fix bug，标明 issue 标号链接
• 将改动拆分成独立的模块进行提交
• 在日志中说明：改动的原因（指向需求文档、设计稿的链接）、改动的内容、涉及到的模块、可能的副作用
• 控制 MR 的代码规模，避免出现海量改动的 MR
• 不要将无用的编码中间步骤提交，本地分支的 commit 可以使用 git rebase 进行合并，即：保证每个 commit 都是可编译通过、带有完整功能的版本。

冒烟

冒烟检测保证提交的 MR 是可编译通过的，检查：

• 可以正常 Debug，运行 App
• 可以登陆、连接服务器、连接 socket，拉取数据。
• 核心功能运行OK

功能实现

检查是否按照需求实现了功能（或者 fix 了 bug）。不必进行详尽的覆盖，作简单的检查就可以了。

• UI是否还原了设计？
• 功能的主流程是否按预期跑通了？
• bug是否修复了？
• 是否影响了其他模块？改动涉及的模块是否运行OK？

性能和体验

对于新的功能模块，在功能实现需求的前提下，还要保证性能和用户体验

• 检查设计稿没有提及（或遗漏）的 UI 交互是否合理，是否需要和产品、设计进行讨论确认
• 检查页面的UI是否流畅，是否有不合理的闪烁、跳动、掉帧
• 检查一些操作是否卡顿、等待时间是否过长
• 检查模块内存占用是否过高，是否有内存泄漏的问题（Instruments -> Allocations / Xcode -> DebugSession -> View Memory Graph Hierarchy）
• 检查模块是否占用大量计算资源，导致手机发烫

编码风格

检查代码保证代码命名清晰、结构合理、风格统一。

好的代码应当是可读性很强的，在水平差不多的情况下，如果难以读懂别人提交的代码，一定是编码结构、风格、命名等出了问题，这是在 Review 阶段应该提出改正的。

具体的编码规范应该参照 杏仁医生 Objective-C 编码规范。

分成以下几个方面对编码进行检查：

命名

• 检查模块、类、方法、变量命名是否合理清晰，是否有歧义
• 检查是否正确使用了前/后缀，没有命名冲突

组织

• 检查是否有过长应该拆分的方法（原则上一个方法不应该超过一页）
• 检查是否有过长的源文件（原则上一个源文件不应该超过1000行）
• 检查代码换行、注释、分块是否合理
• 检查文件的组织是否合理，模块内文件拆分合理、存储位置正确

注释

• 检查每个源文件是否正确添加了说明
• 对于容易引起歧义、不好理解、奇怪的代码段，检查是否添加了必要的注释
• 检查关键接口、参数是否添加了必要的注释

接口

• 检查接口是否清晰，表意清楚，没有副作用
• 检查接口设计是否合理，保证了模块的独立性和扩展性

编码

最后是检查具体的编码内容，这一步不作具体的要求，属于编码经验、数据结构、模式设计等高级知识范畴，每个人有不同的理解。目的是提高代码的质量，共同进步。

一些编码检查可以注意的点：

• 是否重复造轮子了？
• 如果使用别人的轮子，这些三方库、开源代码、借鉴的实现方案等等是否好用合理？有没有更好的方案？
• API 使用有没有兼容性的问题？
• 数据结构是否合理？复杂度是否OK？有没有优化的空间？
• 设计模式是否OK？扩展性鲁棒性怎么样？