前言
- 代码审查可能会很痛苦
- 软件工程师经常抱怨审查过程缓慢，延迟下游任务，并在您在打开的拉取请求 (PR) 和下一个任务之间来回导航时导致上下文切换
- 代码审查也可能充满吹毛求疵，这对所有相关人员来说都是一种糟糕的体验
- 为了解决这个问题，一些工程师甚至建议我们完全摆脱拉取请求和代码审查
- 虽然这可能适用于初创公司的小团队，但我认为这不是每个人的正确解决方案，尤其是企业级公司
- 相反，有很多方法可以让代码审查过程对代码作者和代码审查者都有更好的体验
1-保持小的拉取请求
- 每个工程师都害怕审查更改了 1000 多行代码的拉取请求
- 这些审查可能需要几个小时才能完成，而且通常最终发生的是审查者开始浏览代码而不是仔细审查它
- 解决方案是保持你的拉取请求很小
- 小型 PR 更容易且能更快地审查，因为审查者不需要花费太多时间来建立所有更改如何协同工作的心理模型
- 更改的代码也更少，这有望等同于更少的错误、更少的评论以及更少的作者和审阅者之间的来回循环
- 一开始，保持你的 PR 很小似乎很困难，但如果你将工作分解为小任务并保持专注，就可以做到
- 不要在实现新功能或修复错误的同时进行重大重构
- 在代码中使用功能标志，这样您就可以将一小部分新功能合并到主分支中，而不会出现在生产应用程序中
- 保持你的 PR 小，您的审阅者将不胜感激
2-使用拉取请求模板
- 另一个烦恼是被要求在没有任何上下文的情况下审查拉取请求
- 当一个 PR 没有任何解释地丢在你的腿上时，你常常会想，“这个 PR 是干什么用的？这解决了什么问题？有没有相关的任务？为什么采取这种特殊的方法？
- 拉取请求模板是一种可配置的小型表单，您可以将其设置为每个新拉取请求的默认文本
- PR 模板提示代码作者为其 PR 提供相关详细信息
- 通常，PR 模板会要求您简要说明您所做的工作及其原因、任务单的链接以及用于验证更改的测试计划
- 好的 PR 模板通常还包括一个简短的清单供代码作者检查，以确保他们没有错过任何基础知识
- 该清单可能包括单元测试、文档、国际化、跨浏览器支持和可访问性等项目
- 下面是一个示例拉取请求模板：
3-实施响应时间 SLA
- 如果您发现拉取请求未经审查的时间比您希望的要长，那么现在是为团队设定新拉取请求审查速度的好时机
- 换句话说，PR 在必须被提取之前可以存在的最长时间是多少？一小时？两个小时？24小时？
- 您对该问题的回答可能取决于您团队的规模
- 对于来自您团队的内部拉取请求与来自其他团队的外部拉取请求，您可能也有不同的答案
- 在选择响应时间 SLA（服务水平协议）时，您需要找到合适的平衡点
- 当你发布一个新的 PR 时，期望每个人都立即放弃他们正在做的任何事情并审查你的代码是不合理的，但你也不希望 PR 几个小时都没有被审查
- 找到合适的平衡点，让你的队友进入心流状态
- 他们应该能够编写自己的代码，然后全天在自然停止点审查 PR
- 一般而言，为内部团队 PR 提供 2 小时响应时间 SLA，为外部团队 PR 提供 24 小时响应时间 SLA
- 无论您和您的队友做出什么决定，签订团队协议都可以让您彼此负责
- 如果每个人都同意一个特定的 SLA，并且您的一个 PR 的时间已经过去，那么您就知道可以开始向人们提出问题了
4-培训初级和中级工程师
- 培训机会无处不在
- 指导经验不足的工程师不仅仅是教他们使用的技术和语言
- 它还包括教他们如何进行有效的代码审查等软技能
- 在代码审查期间教你的队友你在寻找什么
- 帮助他们了解什么是重要的，什么不是
- 教他们如何在代码审查评论中进行有效沟通，例如在非阻塞建议前加上“nit”
5-设置持续集成管道
- 当大多数评论是“缺少分号”或“缩进似乎在这里”时，代码审查变得乏味
- 不要在代码审查期间花时间在代码格式化程序和代码检查器可以为您处理的事情上
- 让计算机将琐碎的事情自动化，这样你就可以专注于需要人去做的重要事情
- 您可以使用Travis CI、CircleCI、GitHub Actions或GitLab CI/CD等工具为您的存储库设置持续集成
- 您的 CI 管道将为您运行这些格式化和 linting 任务以及您的单元测试
- 如果 CI 管道在拉取请求的任何步骤失败，它将阻止该拉取请求被合并
- 现在，您已经自动化了代码审查的几个重要部分，从而节省了您的时间
6-使用拉取请求审查应用程序
- 有时不仅需要查看拉取请求中的代码，还需要手动查看应用程序中的更改以验证事情是否正常
- 对于具有复杂设置步骤的应用程序，提取其他人的代码并在您的计算机上本地运行它可能需要五分钟到一个小时不等
- 多么令人头疼
- 拉取请求审查应用程序用于在创建新 PR 时自动将您的代码部署到短期测试环境
- 这允许审阅者轻松检查 UI 更改，而无需下载代码并在他们的机器上本地运行它
- 这不仅可以节省时间，而且还可以通过简化审阅来促使审阅者在审阅中更加彻底
7-生成图表以可视化您的代码更改
- 在 GitHub 或 GitLab 中查看代码时，文件通常按字母顺序显示
- 对于相对较小的 PR，这可能不是问题
- 但是，当 PR 中涉及数十个文件时，有时将这些更改按逻辑组合在一起会很有帮助，这样您就可以在更大的图景中看到它们是如何组合在一起的
- CodeSee Review Maps可帮助您可视化更改了哪些文件以及这些更改如何影响它们的上游和下游依赖项
- 它们与 GitHub 集成以自动在您的 PR 上发布评论和图表
- 您甚至可以创建代码的交互式导览，以帮助指导您的代码审查员
- 最重要的是，CodeSee 地图对开源组织及其公共存储库是免费的
