每年,Github项目 ———The State of the Octoverse 都会分析来自数百万开发人员和存储库的数据,以分享工作习惯、生产力和整体职业满意度方面的趋势。 今年,The State of the Octoverse分享其在社区中看到的模式,以及关于交付代码、创建文档和维护社区的三个更深入的研究。
今年该项目还扩展了新的研究方法。 通过使用来自 40,000 多名开发人员的调查回复来增强来自 400 万个存储库的遥测数据,除了调查结果的定量摘要外,您还可以阅读预测结果和提高生产力的技巧。
每个人都想获得出色的开发者体验。 在工作中,开发人员、经理和组织希望工具和流程快速、愉快且简单。 在开源中,项目领导者和维护者寻找使社区受欢迎和可持续的方法。 那么我们如何才能做到这一点呢?
本文从下述九个方面总结如何更快交付代码。
提高开发人员的生产力
更好的编码和自动化不仅仅是速度和生产力,它还可以改善协作和企业文化。
数据显示:良好的自动化有助于团队更好、更清晰地沟通,研究表明,更好的信息流是更好企业文化的关键。 拥有更好的工具还可以帮助开发人员感到有能力完成他们的工作并感到满足。
使用数据:使用这些图表来确定可以改进工作的一件事! 在底部(箭头末端)选择一些东西,然后向后看有什么影响。 有关每个构造的更多详细信息,请前往我们使用的调查项目的配套存储库。
模型中的每个框都是一个构造(开发工作、文档或健康社区的实践;或做好这些事情的结果)。 每条线是构念之间的预测关系。 当您看到一行时,您通常可以将其解读为“预测”或“影响”。 彩色线为正关系,灰色线为负。 例如,详细的代码审查会积极影响取得进展的感觉——这意味着它们帮助开发人员感到被授权并在他们的工作中取得进展。 但是详细的代码审查会对软件交付性能产生负面影响——这意味着它们会减慢交付速度,团队应该注意权衡。
通过自动化进行快速开发
GitHub 上的开发人员模式反映了自动化软件交付是开源的关键推动因素,可帮助团队在规模上更快地发展。 我们看到大型存储库使用 Actions 的比例高于中小型的报告。
数据显示:一旦大型存储库开始使用 Actions,团队每天合并的拉取请求比以前增加了近 2 倍(增加了 61%),合并速度提高了 31%。 在所有开源存储库中,使用 Actions 将合并拉取请求的数量增加了 36%,并将合并时间缩短了 33%。
使用数据:自动化有助于团队。 尝试围绕您的拉取请求实施自动化,以提高团队的生产力。
代码重用
在 GitHub 的开源社区中,使用社区代码和工具链构建的项目正在蓬勃发展。 我们一起建设得更好,并帮助彼此变得更强大。 Docker 等社区依赖于数以万计的存储库、数十万的贡献者,并且来自数百个国家和地区。
数据显示:权利程序、访问限制或信息碎片可能会导致阻碍开发人员重用代码的冲突。 然而,当重用他人的代码很容易并且不会引入冲突时,开发人员的工作性能可以提高多达 87%。 对于开源项目来说,无冲突代码重用的好处也是惊人的——与那些有更多冲突的项目相比,项目的性能提高了 2 倍,比如缓慢的流程或多个审批层。
使用数据:当您和您的团队重用来自其他团队和存储库的代码时,确定冲突的来源。 是否存在诸如冗长的访问批准、不良索引或未记录的依赖项等障碍? 你可以简化什么,或者影响别人简化什么?
快速的代码搜索
数据显示:当开发人员可以轻松找到他们需要的东西时,他们感到有能力完成工作的可能性要高出近 60%。 此外,只需拥有一个易于搜索的团队存储库,他们就可以将生产力提高 11%——这一发现也得到了早期研究的支持。
使用数据:考虑您的团队实践; 它们是否支持简单的索引和交叉引用,以便更容易找到信息?
考虑员工现在以及未来的办公地点
在今年的调查中,我们看到了工作发生地点的变化以及这对协作的意义——现在和未来。 世界各地的开发人员明确表示希望在混合或完全远程的环境中工作。
数据显示:只有约 11% 的受访者希望回到同地办公,比之前在办公室工作的 41% 下降了 30%。 因此,我们认为混合和远程工作作为预期的工作方式越来越受欢迎。
使用数据:想想你自己的团队,你现在在哪里工作,未来你将在哪里工作。 您如何支持自己和您的团队? 您是否使用流程和工具来支持高效协作? 当我们的部分或全部团队远程工作时(全部或部分时间),合并拉取请求、通过管道部署代码和组织工作变得尤为重要。 我们在开源领域的同事已经这样做了多年,所以他们可以教我们一两件事关于在分布式团队中交付软件。
当深入研究数据时,我们发现公司员工的差异更为明显。 在那些在公司工作的受访者中,46% 以前在同地工作的受访者现在希望在完全远程 (20%) 或混合 (26%) 的环境中工作。
合并pull requests
数据显示:今年,拉取请求在工作中的合并速度最快,几乎是开源的 2 倍。 我们还看到工作中的拉取请求的合并速度比去年慢 25%。 当我们比较前两年时,我们可以看到工作节奏正在恢复到大流行前水平的迹象。
使用数据:想想你自己的工作。 您注意到您的团队或社区今年完成工作的速度如何? 如果您自己团队的合并时间发生了变化,是什么导致了这种情况?
协作pull requests
当我们根据贡献者的数量查看合并拉取请求的时间时,我们发现当其他人共享工作时我们工作得更快,但太多的贡献者会增加协调成本并减慢工作速度。
例如,平均有 30 名贡献者的开源存储库在一天或更短的时间内关闭他们的拉取请求,而那些平均有 65 名贡献者的开源存储库需要三天或更长时间才能关闭拉取请求。
数据显示:大多数拉取请求在前两周内很好地关闭; 我们的图表在两周时截断,但早期合并的模式很明显。 按小时查看合并,我们看到合并在周末下降,但一些进展仍在发生。
在工作中完成的开发中,大多数拉取请求也会在最初几天内关闭。 除了开发之外,我们看到了与开源合并类似的模式
使用数据:查看您自己团队的拉取请求合并时间(或四处询问)-您通常合并的速度有多快? 有没有改进的机会? (如果是,请继续阅读!)
新的贡献者会影响合并的事件
数据显示:随着新团队成员加入或了解代码库,它会影响合并拉取请求的时间。
使用数据:查看您自己团队的拉取请求合并时间。 新贡献者会影响拉取请求合并时间吗? 想想您的团队如何使用拉取请求来培训新的贡献者,或者您如何在团队中共享拉取请求,以及这如何影响整体拉取请求时间以及团队文化。
新贡献者的数量会影响合并拉取请求的时间,例如当新团队成员加入或了解代码库时。
提高快速合并拉取请求的能力
为开源存储库中的拉取请求分配不超过三个审阅者会增加它在 24 小时内被合并的机会。
在工作中,只有一个审阅者的拉取请求通常会在 8 小时的工作日内合并。
自动化和社区帮助我们一起建设得更好。
额外的审阅者是检查错误或不一致逻辑的额外眼睛。 与此同时,随着拉取请求每增加一个审阅者,在一天或更短的时间内合并它的机会就会下降大约 17%。 拉取请求的审阅者数量可能是质量和速度之间的权衡,团队应该进行判断。
使用数据:通过限制您自己团队中审阅者的数量,确定一些加入 Day-or-Less Club 的机会。 这可能包括轮换审阅者,或跨团队分担责任。
本文转载自GitHub Blog,原文链接:https://octoverse.github.com/writing-code-faster/。
[…] 接上篇《Github分析400万仓库和访问4万个开发者总结了九条快速代码交付的建议》,本文从开发文档角度展示Github在分析400万仓库和访问4万个开发者之后,得出来的关于项目开发文档重要性的结论。 […]