大家好,我是鸭鸭。
今天给大家分享一波 Code Review 中的实用小技巧,熟练掌握这些小技巧后,保证能让你在同事的代码面前迅速打出 LGTM~
Code Review 的意义在于让可靠的代码更快地加入代码仓库。至于为啥要用 Gitea 做 Code Review,我认为好处还是挺多的,举几个简单的例子:
- 文件的改动清晰明了,避免引入一些不必要的修改
- 与工单、项目、消息系统深度整合,构建了一套完整的工作生态链
- 与 Jenkins、Drone 等工具集成,确保同事 review 代码前已经跑过单元测试
创建 PR,清晰地告诉别人你修改了什么
Code Review 往往都是从 PR 开始的。一个好的 PR 往往有清晰的描述,首先是一句话概括做了什么,然后再列出具体更改的部分方便审查者迅速把握主题。
同事收到 PR,使用 Gitea 在线代码评审
代码评审是从代码的功能、设计、复杂度、自动化测试结果、代码风格、文档等进行评审,目的在于保障软件质量。前面你已经提交了一个 PR,那么审查者如何利用 Gitea 更方便地检查你的代码呢?
Gitea 提供了多种便于 Code Review 的功能,这包括
1.使用 Diff 格式突出显示文件的前后差异
在 Gitea 的网页中预览代码上下文中的更改时,每一行绿色的 + 号所表示的新增的内容,红色 - 号表示移除的内容,而未更改的部分会被折叠,除非手动展开。因此你可以基于 Gitea 准确找到上下文中做出更改的部分。
除了上述基本能力,Gitea 还针对特定场景进行了优化:
- • 在 Gitea 可以对比新/旧图片差异
- • 支持对 LFS 存储的文件进行差异比较
- • 优化CSV文件呈现效果,除了显示新增行和删除行,还能区分新增列和删除列2.在分列视图和合并视图之间自由切换,任选一个舒适的姿势观察代码。
3.自动折叠已经审阅过的代码,下次审查时无需从头开始。一旦代码发生变更,修改过的部分也会被展开显示。
4.自动记录 PR 的修订历史。在每一个合并请求(Pull Request)中存在一个时间线样式的信息列表,这里汇集了 PR 的提交历史、评论、引用,即使你提交的 PR 经过多次修改,时间轴都可以准确记录每一次变更历史,对比每个版本的文件差异。
5.使用 git blame 显示文件修订历史。在 git blame 视图中,你可以查看选定的文件内容是如何随每一次代码提交演变的。
6.在文件变更视图中为每一行代码添加评论。和 GitHub 一样,Gitea 也具有社交属性。用户不仅能在 Issue、PR 中留言,甚至还能在每一行代码上作出评论,这便于根据代码讨论具体的问题。
7.在 PR 中指派成员跟进代码评审。如果你需要你伙伴进行代码评审。只需要在你的合并请求中邀请他们,此后邀请将通过站内信、邮件等多种途径通知对方,告知你需要他们的反馈。
8.将 PR 与工单绑定。每一个 PR 都是在解决一个问题,将 PR 与工单进行绑定,不管是提出问题的人还是其他开发者都能够清晰地了解当前的工作进展。
9.量化你的工作时间。Gitea 提供了一个独特的时间统计功能,帮助开发者在工作中统计处理问题所消耗的时间。设定任务到期日期,可在工单、合并请求列表中根据自定义的时间先后顺序完成计划的工作任务
结合自动化工具,在评审前完成单元测试
单元测试也是代码评审的重要环节。在人工审查代码前,用机器跑一跑测试就能发现一些简单问题,节约审查时间的同时便于开发者及时纠正错误。
Gitea 可集成 Drone、Jenkins 等常用的 CI\CD 工具,结合 SonarQube 进行代码质量分析。更多的集成方案,请参考Awesome Gitea[1]
一些实用的建议
引用自谷歌工程实践[2]
作为审查者,您应该确保
- 代码设计精良。
- 该功能对代码用户是有好处的。
- 任何 UI 变更都是合理的且看起来是好的。
- 其中任何并行编程都是安全的。
- 代码并不比它需要的复杂。
- 开发人员没有实现他们将来可能需要,但不知道他们现在是否需要的东西。
- 代码有适当的单元测试。
- 测试精心设计。
- 开发人员使用了清晰的名称。
- 注释清晰有用,且大多用来解释为什么而不是做什么。
- 代码有适当记录成文档。
- 代码符合我们的风格指南。
作为开发者,您应该确保
- 书写简短的摘要?是什么、做什么
- 每次只提交较小的变更。便于审查
- 以平和的心态对待审查结果,尝试解决问题和冲突
引用链接
[1]
Awesome Gitea: https://gitea.com/gitea/awesome-gitea[2]
谷歌工程实践: https://google.github.io/eng-practices/review/reviewer/looking-for.html