GitHub以其独特的全球影响力，对开发者体验有重大作用。那么，GitHub是如何衡量开发者效率的呢？我们与GitHub高级工程总监Akshaya Aradhya进行了交谈，以了解她的团队如何提高整个科技公司的开发效率。
译自 GitHub Developer Productivity at 30 Billion Messages per Day，作者 Jennifer Riggins 是一位讲述技术文化故事的记者、作家，以及活动和播客的主持人，帮助分享文化和技术碰撞的故事，并解释我们正在构建的技术的影响。她一直在......
如果 GitHub 被 85% 的软件工程师使用，那么 GitHub 的开发者体验就成为了开发者生产力的套娃。作为全球最大的存储库，仅 Copilot 这个六个月大的 AI 结对编程员就有 1.42 亿 GitHub 用户，这赋予了它独特的能力来全球性地影响开发者体验。
这种规模也使事情复杂化。GitHub 具有 99.9% 的服务级协议，为近 4 亿个存储库中的用户提供服务。这使得全球最大的软件开发平台每天支持难以置信的 400 亿条消息——是的，确实是百亿。
在我们持续不断释放开发者生产力的过程中，The New Stack 采访了 GitHub 的高级工程总监 Akshaya Aradhya，以了解她的团队如何增加 GitHub 整个公司的生产力——这反过来应该可以增加绝大多数技术组织的生产力。
她的团队是 GitHub 基础设施和平台工程组织的一部分——横向支持着整个公司，包括:
- 应用团队
- 代码搜索
- GitHub Actions
- Copilot
- GitHub Next R&D 团队
- 与 Azure 云的未来合作
平台团队由近 300 名 GitHub 员工组成，Aradhya 领导其中约三分之一。平台团队还在他们所做的一切中与另一个主要的横向实体——安全团队有着紧密合作。
她的组织过去被称为数据服务，负责她所说的与数据相关的传统问题，包括数据管道、运营的数据方面以及消息队列。
“我们有 Hydra 和 Aqueduct，它们每天处理数十亿条消息——大约 300 亿条消息，”她解释道，“如果包括上层的开发者生态系统，这个数字会更高。”
她约 120 人的团队还解决 GitHub 内部和外部的所有数据存储问题——对象存储、冷存储、blob 存储——以及数据模式、新一代扩展性问题、生产力问题等。Aradhya 告诉 The New Stack，她的团队关注的是：“我们如何真正倾听开发者的声音，然后与我们自己的应用程序交谈，用我们自己的数据进行测试，学习，然后提出产品？”
然后，他们当然要对一切进行测量以实现持续改进。
“如何提高开发者的效率和生产力，同时确保无缝部署，最大限度地使人们易于解释代码，并自动化人们所喜爱的东西，特别是当你在不同时区运营分布式团队时？” 这一切都让 Aradhya 的团队着迷于使他们高度全球化的开发者团队能够克服最令人沮丧的瓶颈。 “为什么我需要一直等到德国和阿姆斯特丹的人醒来？我被卡住了。”
由于 GitHub 在大流行之前就已经是一家远程优先的公司，其成千上万的工程师成为了很好的首批客户和持续的反馈来源，比如在新人培训上。
“当你进入软件行业时，会被告知‘哦，XYZ 是一名团队负责人’或者‘这是一名高级工程师，如果你不明白代码就询问他们。’然后就是找到那个人的等待时间，为了知识转移而向你解释代码，以及如果你想再次提问却忘记了内容时会产生的尴尬。” Aradhya 说，这对任何人来说都很尴尬，特别是新手，但对许多人来说这简直就是不包容。
“有很多神经多样性社区会说‘这是我的执行功能技能的问题。我希望不会因此而被评判。’”
凭借这种反馈——以及可能来自 GitHub 员工中 30% 自我认定为神经多样性的员工的亲身经历——该团队构建了一个功能，当你选择一段代码时，Copilot 的聊天功能(想象 Clippy 但更强大)将解释代码的工作原理。
“适用于任何 ID。无论你在工作什么。你的 Copilot 会建议方法，并告诉你代码的工作原理。”她解释道，比如确保你没有从不同的类中写错误的方法名。这有助于增强开发者的信心，同时也提高了编写代码的速度，同时减少了引入 bug 的可能性。
这种针对内部开发者反馈的创新就是 Copilot 采用率超过所有预期的部分原因，自去年 6 月首次公开发布以来，美国的 GitHub 用户已有约 92% 的使用率。
这也是 GitHub 全面实践一切的结果，充当第一批客户和测试人员。
“在我们将任何东西推向 GA 之前——甚至是任何东西的 alpha、beta 版本——我们都希望确保它是开发者就绪的。”她说。这体现在 GitHub 的价值观中，其全部围绕促进协作和归属感，这是由持续的反馈驱动的。
“当我们协作时，我们总是会问与生产力相关的问题，比如：你认为 AI 对你的开发者体验有什么影响？我们使用这些信息将其与企业会怎么想联系起来。我们如何帮助企业公司——无论是苹果、沃尔玛、特斯拉还是谷歌——理解和支持工程团队？”
与我们谈过开发者生产力的许多其他组织一样，大量此类反馈都是通过开发者调查收集的。
“当我们谈论开发者体验时，人们往往倾向于将其传统上联系到产品或体验，比如 UI。但它远不止于此。” Aradhya 解释道。“从数学上讲，它是开发者生产力加上开发者产生的影响再加上开发者满意度。如果你把这些全部加起来再乘上一个指数，那么开发者体验就是所有这些的总和，还要更多。”
GitHub 的研究团队随后发布内部博客，并且在早期，他们的 DevEx 见解就参与了产品市场拟合性讨论和高管会议。
GitHub 研究一致认定的早期痛点之一是等待测试完成或构建结束——Aradhya 将其称为死于等待协作：“你如何与人交谈或了解每个人在做什么？你如何自动化代码审查？你如何加快构建速度？你如何处理 bug？”
这就是 AI 发挥作用的地方。实际上，虽然许多人正在夸耀个别开发者生产力的早期收益、更快的事故响应和错误减少，但 2023 GitHub Octoverse 报告(该报告每年调查所有拥有 GitHub 账号的人)的最令人惊讶的结果之一发现，81% 的受访者预计 AI 将增加基于团队的协作。
内部调查也呼应了这一点，GitHub 的开发者要求更多地衡量他们的协作——因为你无法改进你无法衡量的东西。但是如何衡量人与人之间的互动呢？Aradhya 说，这远远超出了 Slack、Jira、拉取请求和文档等基本要求。在开发者生产力领域，这种对协作改进因素的检查考虑了同步和异步通信的广度。他们可以从这些工具和消息队列中获得重要的定量指标。她的团队还关注可发现性的平台工程目标:
- 你如何知道如何发现某些事物？
- 你如何衡量两个人或团队之间的信息流？
- 你正在处理正确的问题吗？
- 你参加了正确的会议吗？
- 你能保护你的时间以达到开发者流状态吗？
在这家远程优先的公司，个人有很大的责任去理解他们的最佳工作方式，并能够自我组织他们的重点时间块。GitHub 会有更高比例的神经多样性队友并不奇怪，因为这是一种非常包容的工作方式。GitHub 还为所有员工提供无意识偏见、特权和盟友训练。
GitHub 的协作指标有意包括了多样性、公平性、包容性和归属感。和大多数技术公司一样，Aradhya 提到，他们在指导妇女和其他技术领域代表性不足的人口方面存在问题。
“我们在指导赞助[和]导师-学员关系方面存在挑战。”她说。不仅在建立正式指导计划方面，而且“我们也存在这样的问题：人们以为他们是别人的导师，但他们为学员创造的价值不够，或者学员并不认可他们可以指导自己。”这种负面经历不成比例地影响那些来自代表性不足群体的人。
为了响应这些反馈，他们建立了更正式的指导过程和培训。
庞大的 Octoverse 报告只是众多内部和外部数据来源中的一项年度调查。虽然团队能够获得定性指标，如著名的 DORA 核心四大指标，但在任何开发者生产力工程旅程中，通常都有定量和定性调查的组合，包括 SPACE 框架和 DevEx 指标。
Aradhya 说，GitHub 研发部门每周快速测试概念验证，几乎是即时反馈。平台和基础设施团队每几周到每季度运行不同的开发者体验调查。她向我保证，决不会是没人愿意回答的三页调查，而是采用更高回复率的较短调查的组合。
“并非一切都需要调查。”她继续说道。例如，产品团队正在不断从客户对话中采取行动，并在活动期间进行快速评级系统反馈。
“我甚至还记得在一个工程领导会议上，我正在午餐休息时间排队等餐车，然后有人看到我的 GitHub 夹克，他们就说，‘你是做什么的？’我说我们支持 XYZ 和 Copilot。我一说完，他们就开始对我提出功能请求，”她回忆道，“等到餐车队伍结束的时候，我已经收到了 18 个不同的意见，我们可以增强或改进的不同产品”，她立即将其反馈给各自的产品团队。
GitHub 是一家以反馈为驱动的公司。Aradhya 说，开发者生产力和开发者体验的度量是高管会议的一个持续话题。
在 GitHub，这些生产力指标包括:
- 获得用户反馈需要多长时间？
- 异步通信是什么样子的？
- 你能在多长时间内不间断地开展工作，没有会议或中断？
- 你花费多少时间建立新问题的解决方案？
- 你花费多少时间编写代码或修复错误？
- 你多久遇到一次安全或漏洞问题？
- 在新产品发布或更新期间，你花费多少时间用于自我提升？花在他人指导和提升上的时间有多少？
- 你花费多少时间编写自动化测试？
- 你多久切换一次上下文？
- 你觉得自己的生产力如何？
她解释说，许多这些更小的内部指标与更大的指标相关联。例如，当 Aradhya 还是一名工程师时，她意识到短期内自己运行一个生产测试会更快，但从长远来看，不编写可重复的自动化测试就是浪费时间。将重复性工作自动化出去是开发者生产力工程的一个重要目标。
她说，和她的团队负责人一起，“我会盘点某些事物涉及的人工接触点数量。”同样重要的是要衡量开发者可以花费在解决独特问题上的创新时间，她说这对留存至关重要。“这是在设计新颖指标——新颖的交流、新的 API、用于所有最新问题。基本上，你是否具有 10 倍的心态，你是否理解客户的问题以及你想用什么方法来解决它？”
这些是 Aradhya 称之为她的团队努力寻找解决方案的“非常规开发者生产力”东西。GitHub 利用这些指标来培养 10 倍开发者的心态，她将其定义为“一位开发者，他拥有远见和技术能力，可以预见他们在长期和短期可能遇到的问题，并且从扩展用户群体的角度来思考问题，超越产品定义的边界或工程领导定义的边界。”
对规模的考虑对 Copilot 的成功至关重要，因为他们预计它一开始可能有 1500 万用户，但很快就明确约 1.15 亿将是一个更接近的估计值——到那时考虑可用性、可靠性和安全性就为时已晚。
GitHub 推出的任何东西都必须具有扩展性。
“一位 10 倍开发者可以预见这一点，然后提供备份，提供 B 部分，帮助技术战略，以便我们可以了解未知的未知。然后根据消费者需求找到一种扩展方法，而不会让代码质量下降。” Aradhya 说。
总的来说，在拥有 GitHub 的微软公司，她说任何人都有机会成为 10 倍开发者，无论层级如何，都可以带来非凡的思维，以及对公司文化和协作的重视。她举了这样的例子：“你是如何扩大周围团队的规模的？你对他们有何影响？你是否以积极的方式改变了团队或公司文化？”
GitHub 关注的另一个开发者生产力指标领域当然是工具，比如寻找回答以下问题:
- 拥有完全配置的环境意味着什么？
- 在该平台环境之上构建有多容易？
GitHub 还收集了大量自动反馈，一直在寻找收紧反馈循环的方法，从验证和合规性检查到帮助开发者了解自己最没有生产力的地方，尤其是将客户反馈传达给开发者，确保他们结合功能请求。
所有这些都是通过持续不断的匿名和认证调查、问题、拉取请求等方式衡量的。
“如果你用调查淹没人们，他们就会停止回答，所以我们在这里要有创造力，”她说，“而且我们还查看内部运行的自己的分析和渠道。”
所有这些结果都与组织的其他成员进行沟通，解释:
“你花在 X 上的时间百分比是多少。我们用 Y 改进了它。然后再次请求反馈。”她解释说，任何人都可以在内部看到这些信息，全世界所有的工程师都可以。