Code Review-磨刀不费砍柴功！

• 正所谓他山之石，可以攻玉，Code Review 益处多多，应当被视作一种开发文化而不是一种制度
• Code Review和写自动化测试一样，都是磨刀不误砍柴工的工作!

阅读本篇文档之前请大家先阅读如何做好 Python 代码的 Code Review–章老师说

Commit 规范

Commit 原则

✔ 每次代码提交应该都要确保是一个最小的完整功能
✔ 每个 Commit 只应该干一件事
✔ 每次提交后的代码库应该都是正常运行
✔ 每次提交应该按照下面的规范添加操作类型
✔ 每次 Commit 都要明确具体操作类型

Commit 类型

操作类型	前缀	Emoji 符号（可选）	说明
添加功能	Feature 或 Feat	✨	后面要跟着对应功能的任务编号
优化代码（代码结构）	Style	🎨	不影响代码功能，特指代码结构优化
重构	Refactor	🔨	大范围级别项目重构
添加测试	Test	✅	添加单元测试
性能优化	Performance	⚡	提升性能有关的优化
合并代码	Merge	🔀	跟别人冲突了之后执行合并时
临时的脏代码	Shit	💩	屎一样的代码，未来需要优化的临时脏代码
包更新	Upgrade	⬆️	升级 npm 包
包降级	Downgrade	⬇️	降级 npm 包
修复 Bug	Fix	🐛	修复 Bug 的提交
填写注释	Document 或 Doc	💡	为代码编写注释
破坏性改动	Breaking Change	💥	所提供的接口或者方法出现重大不兼容更改
配置修改	Config	🔧	配置修改（如 webpack 中 process.ENV）
配合代码审查的更改	Code Review	👌	配合代码审查提出的改进意见做的提交
开发进行中	Doing/InProgress	🚧	一个大功能开发过程中，必须需要跟着对应功能的任务编号
代码移动或者重命名	Rename/Move	🚚
代码删除	Remove/Delete	🔥

commit 案例

✨ Feat: 车辆管理（查看车辆信息） #650070
🐛 Fix: 电子合同，驳回原因应有必填校验 #640609

Code Review 的好处

• 让高水平的帮助新人成长，指出新手代码中的问题
• 形成代码规范，保证有人离职后其他人能快速接手

如何审核

将代码的审查设置为开发流程的必选项

每次开发新功能或修复 Bug，开一个新的分支，分支要合并到 master 必须满足以下条件

• 所有的自动化测试通过
• 至少有一个人 Code Review 通过
  • 如果是新手的 PR，还必须有资深程序员Code Review通过
• 保证每次审查的代码量也不要太大，减轻审查者压力
  • 提交 PR 时，保证 PR 要小，相对就比较容易 Review，也容易发现代码中可能存在的问题
  • 针对比较大的改动，最好分批提交，以减轻审查者的压力
• reviewer 在不符合规范的代码中插入批注
• Code Review时发现问题，被审查者要积极的对审查出来的问题进行修改
• 像写自动化测试一样，团队 Leader 将Code Review设置为开发任务的一部分，给审查者和被审查者都留出专门的时间去做这件事
• review 的内容，审核人与被审核人有讲不清楚的地方当面沟通，提高沟通效率，避免误解

把 Code Review 变成一种开发文化而不仅仅是一种制度

• 有几个人做好表率作用，榜样的力量很重要
• 对于管理者来说，你激励什么，往往就会得到什么

利用辅助工具

code review 工具链

• 实践方案（
• 根据自己/团队需要对公司用的代码管理平台进行配置
  • 将 master 设为保护分支，或设置严格的权限机制，禁止提交未经 review 的代码
  • e.g. GitLab/GitHub，在Settings->Branches设置保护分支
• 搭建/配置 code review 工具链

IDE 插件

• 前端：推荐用 VsCode 插件Visual Studio Code Commitizen Support来设置提交规范
  • 使用教程：
    • Step1.快捷键command+shift+p打开命令面板输入 conventional commit
    • Step2.选择提交类型
    • Step3.填写 commit 信息、iWork 编号（选），回车完成 push 操作

Code Review 的经验技巧

先设计再编码

• 在做一个新功能之前，写一个简单的设计文档，表达清楚自己的设计思路！
• 找资深的开发先帮忙做一下设计的审查，发现设计上的问题！
• 设计上没问题了，再着手开发！

遇到紧急情况，来不及代码审查怎么办？

• 比如，线上故障补丁，而又没有其他人在线的场景
• 针对本次提交，创建 Tag 标记，代码测试上线后，再让同事通过标记确保的 Tag 补上 Code Review，并对不规范的代码进行修改更新
• 同时在任务管理系统中，创建一个 Ticket，用来后续跟踪 Code Review 是否补上

代码在提交 CODE REVIEW 之前，作者要自己先 REVIEW 和测试一遍

• 把该写的自动化测试代码写上，自己把基本的测试用例跑一遍
• 代码在提交 Code Review 之前，肯定是要自己先 Review 一遍
• 提交 PR 时要求写好描述，有必要时还可以增加截图或录屏，以确保提交 PR 的人自己是先测试过
  • 动图录制工具推荐
    • windows: ScreenToGif
    • mac: LICEcap

对评论进行分级

以对 Review 的评论进行分级，不同级别的结果可以打上不同的 Tag

• [blocker]: 必须要修改
• [optional]：表示这个代码行的问题可改可不改
• [question]：表示对这个代码行不理解，有问题需要问，被审查者需要针对问题进行回复澄清

评论要友好，避免负面词汇；有说不清楚的问题当面沟通，面对面的沟通效率更高，也容易消除误解。

参考：
不容错过，前端 Code Review 的最佳实践方案来了

在 Bitbucket 中进行 CodeReview

• Step1. 项目相关 Coder 对不合理的代码进行评论，出现分歧的点再找组内其他同事参与一起评估
• Step2. 相应开发将提议内容修改后，对被 comment 进行回复，如果仍 review 不通过则继续进行步骤 2
• Step3. 所有 comment 内容都 review 通过，重新提交 pull request, 再次进行步骤 1，如无问题，再通过 pull requests，将代码合并进入主分支

CodeReview 反例

• 一堆人拉一个会议室 Review 代码（浪费时间）
  • 发 Pr 到群里，让大家抽时间看，然后提 issue 即可