建网站代理哪个,logo网站设计论文,建网站 几个链接,应用分析网站目录
前言
1-保持小的拉取请求
2-使用拉取请求模板
3-实施响应时间 SLA
4-培训初级和中级工程师
5-设置持续集成管道
6-使用拉取请求审查应用程序
7-生成图表以可视化您的代码更改 前言
代码审查可能会很痛苦软件工程师经常抱怨审查过程缓慢#xff0c;延迟下游任务延迟下游任务并在您在打开的拉取请求 (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 地图对开源组织及其公共存储库是免费的
