iOS 端 Code Review 指南 - 文章教程

iOS 端 Code Review 指南

发布于 2020-10-20 字数 3235 浏览 1603 评论 0

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

指南不仅针对 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 阶段应该提出改正的。

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

命名

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

组织

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

注释

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

接口

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

编码

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

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

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

如果你对这篇文章有疑问,欢迎到本站 社区 发帖提问或使用手Q扫描下方二维码加群参与讨论,获取更多帮助。

扫码加入群聊

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

目前还没有任何评论,快来抢沙发吧!

关于作者

JSmiles

生命进入颠沛而奔忙的本质状态,并将以不断告别和相遇的陈旧方式继续下去。

2583 文章
29 评论
84935 人气
更多

推荐作者

清欢

文章 1 评论 0

贱贱哒

文章 3 评论 0

悸初

文章 2 评论 0

西瓜杏

文章 0 评论 0

各自安好

文章 0 评论 0