利用越权漏洞（IDOR）实现账户劫持

Commit Message 可以在 git 中配置模板，这样可以在 vim 中展示出模板，另外可有工具帮助我们生成和约束 Commit Message，例如 commitizen/cz-cli，这里不再具体说明。

2.1.3. CI 通过

CI（Continuous Integration），持续集成可以帮助我们自动发现很多代码中的基本问题，在合适的静态代码检查（lint）配置和良好的单元测试覆盖下，CI 可以有效地提高代码的质量。很多人都低估了静态代码检查的能力，实际上现在常见语言的静态代码检查已经能帮助发现不少的 bug 和隐患。对于 Go 语言，可以配置 golangci-lint 来做代码检查，单元测试根据实际情况可以制定相应的标准，比如覆盖率 60%，其中关键的代码逻辑尽量全面覆盖。

提交代码 Review 前需要确保 CI 执行通过，这也是为了节省 Reviewer 的时间，能够通过自动化解决的事情，尽量不要让 Reviewer 来做，而 Reviewer 发现 CI 未过的 MR 也可以要求 Author 先解决 CI 问题。

2.1.4. Self-Review

我们一般代码 Review 都是找他人来进行 Review，其实负责任的 Author 在邀请他人来代码 Review 前也需要自己简单 Review 一遍，即 Self-Review。

Self-Review 的目的包括：

• 发现那些明显的疏忽，如代码 debug 过程中留下的不必要的痕迹，比如 fmt.Println(...)，不小心注释掉的代码。
• 之前被 Reviewer 多次提出过的问题。
• Commits 是否正常，在多人协作的情况下 MR 中否带入了不相关的 Commit。
• Commit Message 是否合适。

Self-Review 是一个非常快速的过程，从我个人的经验，一般 1-2 分钟即可完成，所以推荐大家养成 Self-Review 的习惯。

2.2. 第二招：该找谁来 Review

从目的出发，可以从以下几方面考虑 Reviewer：

• 提高代码质量。所以首先应该找和代码改动紧密相关的研发人员参与 Review，比如一起开发某个功能，某个项目，或者一起参与了方案设计讨论并给出了有价值意见的研发。
• 获取意见。找有相关经验的资深研发帮忙 Review，比如 Java 语言资深的研发、写过相同或类似系统/功能的研发。
• 形成共识。如果涉及到不同团队或模块间的接口改动，或其他会影响其他人的改动，可以邀请相关团队或模块的接口人参与 Review，以对改动形成共识。
• 质量把关。对于重要的代码库，可能会执行比较严格的质量把控，如果设置了必须的 Reviewer，这些 Reviewer 也会参与进来。
• 变动告知。很多情况下一个代码库可能只有一个人维护，如果做了些比较特殊的变动，其他人很难发现。因此在做一些重要的但是理解起来不那么直接的地方的时候，最好告知一下相关的研发，以便他们能大概知道发生了什么。

2.3. 第三招：都 Review 些什么

经常会有 Reviewer 拿到 MR 不知道该 Review 些什么，其实无论你参与对应项目的深入如何，都可以对代码进行 Review，也鼓励不同人从不同的深度、角度去帮助 Review。代码 Review 没有固定的形式，它更像是一门艺术，唯一的提高办法就是实际参与进去。

Review 的时候可以从以下几个方面入手：

1）简单的 Review

在 CI 通过的情况下，最简单的 Review 方式可能只需要这样：

Reviewer：在实际环境中都验证过了吗？
Author：当然验证过了
Reviewer：LGTM

这是一种提醒式的 Review。确认一句：是否在环境中验证过了，或者进一步把能想到的重要的验收点提出来确认一遍。即使是这种最简单的 Review 实际上也是有价值的，我们很难保证所有研发都会在提 MR 前实际在环境中验证自己所做的修改，也很难保证单元测试、e2e 测试能 Cover 住所有的情况，Reviewer 基本上也不可能都自己去环境上跑一遍。让 Author 去确认实际上就是提醒 Author 去确保改动至少是真实有效的，尤其是对一些已发布版本的 Bugfix，一定要提醒实际自测通过。

类似的提醒还包括：相关的文档（外部的）是否相应更新了、这个改动是否会有兼容性的问题、性能是否有影响。他们的本质就是提醒 Author 自己去思考他们可能遗漏的问题。

（编辑：唐山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!