GitHub Copilot就像科幻电影中的场景——一对 AI 程序员，似乎能够在你编码时读懂你的想法。GitHub Copilot 使用经过数十亿行公共代码训练的OpenAI Codex，在开发人员的集成开发编辑器 (IDE) 中实时建议代码甚至整个功能。使用 GitHub Copilot 可以提高开发人员的工作效率，但它不是灵丹妙药，也不能替代良好的编码实践和 DevSecOps 流程。在这篇文章中，我们将探讨如何考虑 GitHub Copilot 以有效和负责任地使用它。
人工智能配对编程——下一个前沿
计算机不理解编程语言——它们理解低级命令。但是，今天的大多数开发人员并不使用低级命令或汇编代码进行编码；他们使用更高级的抽象，使编程更容易，效率更高。协助开发人员的 AI 模型很容易变得无处不在，就像第三代和第四代（3GL 和 4GL）编程语言几乎取代了低级编程，尤其是对于商业应用程序。
GitHub Copilot 并不是新闻中唯一的人工智能模型。可能听说过ChatGPT —— OpenAI创建的一种模型，可以回答自然语言问题并协助处理电子邮件等任务，甚至可以根据提示编写代码。OpenAI 还创建了DALLE-2，它可以根据自然语言描述创建写实艺术。
为什么这些基于人工智能的工具变得如此流行？一个原因是他们将用户从如何完成任务的细节中抽象出来，使他们能够更清楚地思考他们想要实现的目标。
理论构建和认知负荷
在Programming as Theory Building (1985) 中，Peter Naur 写道，“程序的构建与程序员团队对其理论的构建是一样的。” 当开发人员进行编程时，他们试图实施一种理论（或模型）来解决业务问题。编程增加的价值不是编程本身，而是它解决的问题。
认知负荷是完成一项任务所需的工作记忆量。编程时的认知负荷大致分为三种类型：内在（知道如何编程）、外在（知道如何构造数组、向数据库添加项目或调用 API）和相关（知道如何解决业务问题） ). 编程需要内在知识，但能够最大限度地增加相关负载量同时减少无关负载量的开发人员效率更高。
想象一下，开发人员正在设计一个电子商务网站：他们需要对产品目录、订单、购物篮、货运跟踪和业务的其他方面进行建模。让我们想象一下产品目录：您希望开发人员将时间和精力集中在哪里——如何最有效地向正确的客户展示正确的产品，或者如何查询数据库以获取产品列表？当开发人员用查询数据库和将对象从后端传递到前端的机制填充他们的“工作记忆”时，他们并没有真正考虑业务问题. 开发人员可能会考虑首先获取哪个产品子集，或者如何定位产品图像以获得最大可见度以增加销量——这些是开发人员试图解决的密切相关的问题。
GitHub Copilot 旨在让开发人员专注于业务问题（程序理论）而不是编程本身。
Context切换
根据2022 Stack Overflow 开发人员调查，63% 的受访开发人员每天花费超过 30 分钟来寻找问题的答案或解决方案（无关的认知负荷）。对于一个由 50 名开发人员组成的团队，StackOverflow 估计整个团队每周损失的时间总计在 300 到 650 小时之间。
context切换已被证明是专注和高效工作的障碍。切换出 IDE 以在互联网上搜索如何实现一些样板代码可能会阻碍开发人员的流程，并且开发人员花在流程上的时间越少，他们的工作效率就越低。在我们的研究：量化 GitHub Copilot 对开发人员生产力和幸福感的影响报告中，使用 Copilot 的开发人员报告说他们的生产力提高了 88%，流程增加了 73%。我们招募了 95 名开发人员用 Javascript 编写 Web 服务器，并为其中 45 名开发人员提供了 GitHub Copilot。这 45 名开发人员完成任务的速度比没有使用 GitHub Copilot 的小组快 55%。
GitHub Copilot 助一臂之力
理解上面列出的挑战，可以开始理解为什么 GitHub Copilot 如此有价值。GitHub Copilot 帮助开发人员花更多时间思考他们正在构建的理论，而不是代码本身。或者在认知负荷方面：GitHub Copilot 有助于减少无关的工作记忆量，以便开发人员可以更专注于相关的业务问题。GitHub Copilot 不是不断地切换出 IDE 来寻找解决方案和答案，而是在开发人员工作时在上下文中综合解决方案，让他们保持流程。
但是我们怎么知道 GitHub Copilot 的解决方案是正确和安全的呢？简而言之，我们没有。与开发人员所依赖的任何其他网站或代码资源一样，它旨在充当副驾驶，而不是自动驾驶仪。虽然 GitHub Copilot 旨在提高生产力，但它并不是要取代开发人员，也不是要取代扫描、测试和验证代码的良好实践和流程。
内部循环中的 GitHub Copilot
在讨论 DevSecOps 时，团队通常会提到内部循环和外部循环。内部循环是在开发人员的开发环境中进行的开发的一部分——他们在本地编码、运行和调试他们的代码（在他们自己的开发机器上或在Codespace中）——以及同行代码审查，通常使用拉取请求。DevSecOps 环境安全工具（例如GitHub Advanced Security）可以嵌入到具有拉取请求安全审查和预防性安全检查的互循环中，以防止漏洞，同时保持高开发速度。外环是持续集成/持续交付的地方(CI/CD) 发生——利用自动化来构建、扫描、测试和部署代码，使用诸如GitHub Actions之类的自动化引擎。
在内部循环（开发环境）中，GitHub Copilot 可以根据开发人员忙于处理的context合成代码片段来协助开发人员，正如我们上面所讨论的，这让他们保持在流程中。那么，开发人员如何知道 GitHub Copilot 为他们生成的代码是好是坏？首先，使用 GitHub Copilot 的开发人员应该对他们编写代码的语言有一些基本的了解。这将帮助他们确定 GitHub Copilot 建议的解决方案是否有效。从那里开始，代码仍应在本地运行和测试。当然，不应跳过代码审查！
外环
外循环应该适用于所有代码——无论 GitHub Copilot 是否帮助创建了代码。组织应该在没有 GitHub Copilot 的情况下将他们今天使用的相同实践和流程应用于验证由 GitHub Copilot 合成的代码。这些实践包括自动 linting、单元测试、静态应用程序安全测试 (SAST)和软件组合分析 (SCA) ——这些可以通过GitHub Advanced Security完成并通过GitHub Actions自动化。理想情况下，还应执行功能、集成、负载和渗透测试。GitHub Copilot 不会使任何这些实践的必要性无效。
结论
GitHub Copilot 是出色的生产力助推器，可帮助开发人员保持顺畅并提高生产力，但不能替代良好的开发和 DevSecOps 实践。随着 AI 驱动的工具越来越受欢迎，企业应确保其团队拥有良好的开发人员和 DevSecOps 实践，以便他们能够自信地利用这些工具。
参考链接：https://github.blog/2023-02-22-responsible-ai-pair-programming-with-github-copilot/
