杏仁医生 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？扩展性鲁棒性怎么样？
