【知识整理】简述 Code Review - 代码审查

最新推荐文章于 2024-09-20 07:30:00 发布

卢卡上学

最新推荐文章于 2024-09-20 07:30:00 发布

阅读量2.5k

点赞数 31

分类专栏： PHP 文章标签：运维 codereview php git gitlab ci/cd

本文链接：https://blog.csdn.net/tjls2008/article/details/136195088

版权

PHP 专栏收录该内容

48 篇文章 0 订阅

订阅专栏

一、Code Review 简述

为保证上线代码质量，经研究决定0412版本起实行Code Review 。具体操作方式为组织 review 会。提出的优化点需立即执行更改，Review会要求给出调整方式方法。同时为了确保项目或迭代版本的时间，请各开发同学提前做好时间规划。此流程为试运行流程，在团队操作过程中 Code Review 方式方法会随之进行优化调整。

这里是来自维基百科的官方解释，CR，全称 Code Review，中文名 - 代码审查，其目的是在找出及修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。代码审查常以不同的形式进行，例如结对编程、非正式的过整个代码，或是正式的软件检查。

二、Code Review 目的

交叉排查缺陷：通过团队成员相互审核，避免代码层面出现显而易见的问题
提高代码质量：通过团队成员相互监督，在完成功能的基础之上不断完善代码结构
建立团队意识：代码是团队财产，团队成员在相互督促与改进中共同成长

Code Review 也就是代码评审。代码评审有两种不同的方法，

一种是代码审查（比较正式）。

一种是代码组查（没那么正式）。

之所以需要代码评审，是因为通常自己对自己写的代码都难以发现问题，因此需要以第二双眼睛再次检查代码，帮助我们及时地发现潜在的问题。

1.确保整体代码标准化统一，在一定程度上避免编程引发的基础原则性问题

2.提高研发质量，为提测和交付上线提供双重保障

3.在满足审核标准的情况下，使PHP组整体代码健康状况随着时间的推移而改善

4.审核代码的质量，比如可读性、可维护性、以及基础程序的逻辑和风险点，针对业务逻辑的正常实现不进行深度review

三、Code Review GitLab操作流程

具体操作分支

第一步分支 test 更改为保护分支，只有指定组长才有权限进行合并操作。具体开发人员只能指定人员发起合并请求。

具体操作通过 Gitlab平台主要Merge-Request机制进行代码审查

1. 开发人员（项目成员）在本地完成一个任务（编码）并通过本地单元测试（自测）。

2. 同步源仓库内容(release_product_hw)至本地仓库「如果跨版了，合并最新代码到本地分支」：可能需要解决冲突，再次进行本地单元测试，通过后push至个人gitlab远程库。

3. 登录Gitlab，进入目标仓库（Project，后续统称目标仓库），发Merge Request，详见下面截图：

选择准备申请合并的 Source Branch 与 Target Branch ，如下图：

输入此次合并的关键信息（功能、解决的问题等），指定代码审核人员并提交Merge-Request。提交后Gitlab将会邮件通知相关的代码审核人员。

4. 相关人员收到邮件通知后登录Gitlab对M-R请求进行处理，也就是进行代码评审。

如果对准备提交的代码不满意，则可以在有问题的代码行或讨论区给出意见或建议。

如果觉得本次M-R的代码没问题，直接在评论区回复：通过。并进行合并操作。若没有 Push 权限，则将此M-R请求 assign 给有 Push 权限的人。

5. 在上一步中，如果代码评审未通过，开发人员（M-R申请者）需要根据评审意见进行修改（当然是得在本地开发环境进行修改测试），即重新根据步骤1、步骤2 进行操作，最新的提交信息会实时同步至此前提交的M-R申请单的信息流中。

6. 代码审查流程重新跳回步骤4 。

7. 具有 Push 权限的开发人员收到M-R请求后，如果讨论区的回复内容为：通过，则执行 Merge 操作。至此整个代码审查流程结束。

M-R申请者也可以提前关闭M-R请求：自己事先发现代码问题等。

如果错误点击了Merge操作，也可以 reopen 。

四、Code Review 时间轴

由开发人员根据开发情况，向即将上线版本（由发版人指定）分支发起 Merge Requests 请求，然后通知相关人进行 CodeReview，功能较大更改文件较多的，组织开 Code Review 会议，确定时间、地点、相关人员。

往往发生的实际场景是项目时间比较紧，尽管提出了问题，但是没有细究，CR 直接快速过了。后面果然有问题，花费了两三天去排查解决，整个模块几乎重写。
通常来说：开发 + CR讨论时间 < 不 CR，遇到问题后面修改，设计不合理的维护成本。所以这里的一个点，前期就接受他的存在，并将它计算在排期中。

场景说明：

你在认真的写代码，然后旁边的小菜开心的喊你帮我看个 CR。作为一个认真负责的你，当然是满口答应，准备点进去看看，过了一秒钟打开GIT网页，发现 365 个文件变更，此时求你的心里阴影面积。

这种场景，其实是一次性囤的代码太多导致的，很多同学觉得，我应该把一个功能完整的开发完毕，再提上去，大家才知道我在写什么，但是实际上，coding 是个循序渐进的过程，建议日常开发的同学控制 commit 粒度，尽可能保证每天提交，以及尽可能写好 commit message，还有就是 commit 跟卡片做好关联，也有助于 reviewer 能更好的理解你的意图。