GitHub 2020 报告：全球开发者工作与生活的平衡情况

GitHub 在 2020 年底发布了 2020 年社区和开发者报告。主要包括全球开发者工作与生活平衡情况，赋能社区健康和全球软件安全报告三个部分，本文分享的是全球开发者工作与生活平衡情况，欢迎关注我订阅其他部分的内容。

前言

2020 年，由于疫情等因素的影响，很多企业和团队都被要求尽可能或者必须远程工作，因此很多开发者都转成了远程工作，这也就要求他们必须重新思考其工作地点和时间安排，调整工作和家庭之间的界限 —— 我们可以看到或许也亲身体会到，这件事儿其实并不简单。在本报告中，GitHub 官方对人们过去工作模式进行了分析，来探求这种变化对开发者体验和生产力到底会产生怎样的影响。

研究发现

通过详细且严谨的数据分析，本报告指出以下四点发现：

修改量小的 pull request 有助于推动创新和生产力：严格将 pull request 的内容修改量控制在较小范围内的团队，代码审阅等相关的反馈速度更快。在过去的一年中，开发者们通过控制 pull request 中内容的修改量，提升了他们工作的速度和质量，并将 pull request 从创建到被合并所需时间控制在了七个半小时以内。这样大家就有更多的时间去做自己想做的事儿了。
自动化可以提升生产力，改善开发者体验：使用 GitHub 的 Action 来对 pull request 进行自动化处理，使得其被合并所需时间缩短了 19%，并使得合并的 pull request 的数量提升了 34%。通过在工作流中使用自动化工具，可以最大程度地降低手动的操作，节省出更多的时间以让团队成员进行创新、开发和其他工作的协作。
当大家都在家时，开源是一种很好的“消遣”方式：数据分析表明，开发者在周末和假期会“离开”工作，而在这段时间开源项目的活跃度却激增。这表明开发者对待工作和开源的态度是不一样的，开发者可能会认为开源是一个提供了学习、成长、创新和与社区互动的一个绝佳的渠道和机会。
开发者活跃度凸显了灵活和个性化解决方案的重要性：本报告通过分析了四大时区的开发活动数据，发现在所有时区中，在过去的一年中，无论是工作时间还是工作量都在增加。并且开发者可能会通过灵活的时间安排来管理他们的时间和精力，这其实有助于延续他们的精力。但需要提醒的是，如果牺牲个人休息时间来工作，打破了工作和生活的平衡，那么长远看来这种方式是没法持续的。

工作建议

根据分析结果，本报告提出了以下四个建议：

管理好个人精力：在家工作时做好工作管理的最好的方式之一就是管理好个人精力，计划好核心工作的时间并完成对应的工作，然后休息一下。利用间隙时间或者精力不是最集中的时间开会。这可以帮助你避免倦怠，避免厌恶工作。
多尝试，找到最适合自己的工作方式：人是很有韧性的。如果公司允许员工灵活安排工作时间，那么开发者就可以优化自己的工作时间安排，管理他们的精力，在精力充沛的时间段完成所负责的工作。灵活的工具和工作流程也有助于提升团队的健壮性，无论大家在哪儿工作，都可以计划、跟踪并进行开发。并且，将工具转移到云上，也就是所谓的云开发，有助于提升开发体验。
使用自动化工具，并控制好 pull request 中的内容修改量，有助于提升开发质量和速度：因为这样可以很好地减少一些手动的操作，有助于提升代码审阅的速度和质量，也有助于提升开发效率，从而更快地交付开发。
拥抱并支持协作和开源：大家对待开源的态度正在发生改变，在“离开”工作后，很多人会选择通过做开源项目的方式来“消遣”。虽然可能还是在同一台电脑上做着类似的事儿 😂。公司和组织应该检查自己的相关规定，尽量允许员工做开源项目。要认识到，开源不仅是一个平台，而是对员工来说至关重要的东西。

全球开发者什么时间工作，工作多久

开发者生产力有多个维度，包括解决复杂问题的能力，找到解决方案并完成需求等。而工作时长和具体时间安排是生产力的一个方面，了解它有助于我们更好地安排自己的工作时间。

本报告此部分的数据来自满足以下条件的付费组织的账户：

创建于 2018 年 10 月 01 日之前，至 2020 年 09 月之间，每个月都在活跃；
付费团队和企业云账户

为了便于进行逐年比较，除另有说明，报告中所使用的数据均经过归一化处理。本报告分析了超过 35,0001 个组织的数据，其中北美 (41%)，欧洲 (35%) 和亚洲 (17%) 的代表最多。因此，本报告主要分析了全球四个时区的开发者工作模式：英国时区（UK Time Zone），美国东部时区（US Eastern Time Zone），美国太平洋时区（US Pacific Time Zone），日本标准时区（Japan Standard Time Zone）。

在过去的一年中，虽然 COVID-19 改变了大家的工作方式和工作地点，但是并没有改变开发本身。在工作环境变化期间调查开发者生产力的最好的方式是，使用一种不会随工作的变化而变化的指标。而 GitHub 上的开发活动是一个很好的指标，即使工作发生了变化，该指标也具有很好的鲁棒性。尽管看板之类的东西可能已经从白板转移到了在线工具，但无论我们是在办公室还是在家里，都可以通过相同的 push，pull request 和 issue 来观察开发情况。这意味着本报告是比较可靠的。

GitHub 的数据没办法体现开发者在某段时间中的生产力高还是低，但我们可以观察开发者的工作模式，以及这些模式随时间的变化情况。这些开发工作模式并不能完全代表开发者的一天，它只能向我们展示开发者在开发部分所花费的时间。因为开发者的工作并不仅仅是开发，还包括各种会议、计划和处理邮件等工作。

但是，这些模式可能会让我们对工作以及其中的变化产生一些新的启发，尤其是今年这种大规模的远程工作的情况。通常在家工作的人，会在工作上花更多的时间 —— 每周加班时间超过 8-16 小时（Hill 等，2010）。这可能是因为我们的工作延伸到了我们的生活中，并且工作和生活之间的界限变得愈加模糊。随着突然转变为远程工作，我们想知道是否会看到任何增加开发时间的模式。

在这些时区中，本报告同时分析了开发窗口（也就是工作时长）和工作量。本报告选择这些时区是因为它们均发布了较为强力的疫情管控措施，这可能有助于突显工作模式所发生的变化。之所以选择这些样本，是因为本报告的样本量足够大，不会受到少数组织的过度影响，并且能够获得显著的结果。

单个开发者的工作日工作时长为其第一个到最后一个 git push 之间的时间长度，这被称为“push 窗口”。这是对开发者开发窗口的开始和结束的一个粗略评估。

在此时间范围内，本报告按 push 次数计算工作量。注意，这里考虑的仅仅是开发工作，而开发只是开发者日常工作的一部分，很多其他工作任务，例如计划、设计、会议和处理邮件等，并且可能会是在此窗口之外的时间进行的。

全球概览

在所有时区中，星期一的 push 窗口都相对较短，大多数工作时长在 4.2 至 4.7 小时之间。
所有时区都在周六和周日工作，并且几乎和周一的工作时长相同。在周六，时间范围为 3.7 至 4.3 小时。在周日，时间范围为 3.7 至 5.4 小时。这可能是大家在赶上一周的需求，或者为下一周做准备，也可能是开发者在做个人项目。
与其他时区相比，周二到周五，美国太平洋时区的 push 窗口明显更长，范围为 8 小时至 8.3 小时。

本报告把所有时区每天的 push 次数进行了对比分析，发现了一些有意思的现象：

在本报告研究的所有时区中，开发者一周七天都有活动。
在所有时区中，日本标准时区中的人均 push 量最平衡，这是最可持续发展的工作方式。并且日本时区政府对 COVID-19 的反应也较为温和，在这里虽然很早就支持了远程工作，但并不是强制的，随意对工作流程的影响可能也没有那么大。日本还是对 COVID-19 最早也是相关管控的最好的国家之一，恢复正常工作的速度也相对较快。
与日本时区相反，美国太平洋时区的人均 push 量最高，这可能是加班文化（在这儿设有两个核心的技术中心），或者是为了和其他跨多个时区的同时写作导致的。但这种工作方式容易让人厌倦工作，并不是可持续的工作模式。

英国时区 push 窗口和工作量分析

首先，本报告对英国时区进行分析，英国是最早发布居家隔离政策的国家之一。英国开发者在 2020 年 04 月之前的 push 窗口与去年同期相比有所缩短，然而在三月中旬开始大幅增长。从八月份开始，push 窗口开始趋于平稳，并且相对于去年同期增长了三分钟。

观察工作量，可以发现英国时区用户的 push 量直到六月中旬才开始增加。并且直到八月和九月，其 push 量相较于去年同期都保持在了一个较高的水平。也就是说，英国时区的人们从六月开始工作时间更长，工作量也更多了。

对英国时区开发者平均一周中的 push 窗口和工作量（平均 push 次数）进行分析可以看出，在这个时区中：

Push 窗口时长大多为周五的 3.9 小时至周三的 4.4 小时之间。
工作量大多为周五的 13 次提交到周三的 15 次提交之间。
周六的 commit 量最高，高达 20 次。

周末 push 量的增加可能是由于周末提交代码的开发者较少。但是还可能代表了个人工作量的升高，例如做开源项目，业余爱好或者教程等。因为在工作日开发者都在忙于工作相关的事儿，所以开发者会利用周末时间来做个人项目。值得注意的是，在除了日本标准时区以外的时区中均有类似的情况。稍会在分析该时区时对此进行说明。

美国东部时区 push 窗口和工作量分析

对于美国东海岸地区，开发者在 2020 年大部分时间的 push 窗口都相对较短，在 3 月份出现过上涨的情况，随后在 8 月份开始趋于平稳，相对去年同期增加了两到三分钟。11 月份数据下跌是因为感恩节假期。

通过对此时区开发者的数据分析可以看出：

工作日 push 窗口范围为星期一的 4.4 小时至星期三的 5.3 小时。
工作量范围为星期一的 12 个 commit 到星期三的 13 个 commit。
星期日的 commit 量增加到最高，为 16 个。
开发者在周日的工作量和周一相当，甚至更高。

美国太平洋时区 push 窗口和工作量分析

通过分析可以看出，push 窗口长度相对于去年同期有所变化，从三月中旬开始增加，普遍每周达 30 至 60 分钟。这种情况一直持续到了六月，在七月初开始趋于平稳。并且，在整个七月下旬相比去年同期增加了 5~7 分钟，到八月再次下降。此外，11 月份的涨跌是感恩节假期导致的。

太平洋时区开发者的 push 量在今年全年始终高于去年。从五月份开始增加，在很多方面的活动相较去年都增加超过了 50%，然后再九月份下降至高于去年 25% 的水平。本次调查通过代码 push 情况可以看出在这一年中，太平洋时区相比于其他时区，开发者工作量一直是最高的。

在这个时区中：

工作日 push 窗口范围为周一的 4.5 小时至周三的 8.3 小时。
每周的工作量从周一的 16 次 commit 到周三的 17 次 commit 不等。
Commit 次数周日最高，为 23 次。

分析还发现了一个有趣的趋势：企业开发者的活跃度在周末和节假日有所下降。但与此同时，开源项目的活跃度却显著提升，这表明大家在放下工作任务的时候转而投向了开源。四月份以来，开源项目的创建量也同比增长了 25%。尤其是在现在还有很多人是处于远程工作的状态。开源使我们有机会进行开发、创造、学习、合作以及与社区进行分享。

日本时区 push 窗口和工作量分析

最后，报告分析了日本标准时区。从 2019 年 11 月中旬开始，日本开发者的日工作时长比去年同期有所增长（提升了 5-15 分钟）。从四月份开始，我们看到 push 窗口开始变得更长，开发者开始每天在工作上多花费 20-52 分钟。六月份，该数据减少到比去年同期每天多花费 15 分钟左右。

在这个时区中：

Push 窗口范围为周五的 4.3小时至周二的 4.8 小时。
每周平均每个开发者每天的工作量为 9 次 commit。
周日工作量降为 8 次 commit。

与在美国和英国实施的封城等类似的封锁措施不同，日本政府所采取的措施本质上是非强制性的，对个人和企业没有任何处罚。因此，工作模式转变的影响可能并不显著。

生产力人人有别

COVID-19 和突然开始远程工作的转变造成了很大的影响。但是，开发者做的工作却比去年同期更多。面对不确定性，生产率却仍在提升，我们感到很高兴，但这真的可持续吗？对部分人来说，在家工作解放了生产力，他们可以根据自身的情况安排工作，按喜欢搭建工作环境，尽可能地降低干扰。并且，有更多的时间午休、锻炼和陪伴家人。这在公司上班的时候是无法实现的，可能是由于开放式工作环境太嘈杂，或者办公环境无法自定义，又或者通勤时间太长，使得无法灵活地安排一天的时间。

但是，对于很多刚开始尝试远程工作的人来说，可能会面临很抓狂的情况。对于某些人来说，远程工作提升了与大家交往和沟通的难度。很多人家里也没有工作区，缺少工作所需设备，还需要自己或者找人照顾孩子。工作和生活的界限会变得模糊，之前用于通勤的时间也变成了工作时间，导致工作时间变长。尽管这样，很多人还是会感觉时间不够用，工作难按时完成。

在这分享几个提交工作效率，避免怠倦的小技巧：

每天花几分钟想一想你所感激的事儿。有开发者分享说，这对他们的心态调整有着积极的作用。
除了管理你的时间，还要管理精力。找到适合自己的能够维持较高工作效率的工作模式，并不断针对这些模式进行优化。如果你喜欢早起，那就先完成重要的任务。如果你在下午或者晚上工作效率较高，那么就可以和其他同事协调好相关工作。
作为团队，应该支持灵活、可持续的工作时间安排，并注意团队成员的倦怠现象。这有助于使我们的团队和我们自身工作得更开心，更有生产力。

更多有关在家工作的小技巧，请查看以下资料：

开发者活动

开发者活动（也就是开发者行为）是生产力的另一个方面。将开发者活动作为生产力的一部分来衡量是十分复杂的，但如果做得好，也很有益处。这可以帮助开发者揭示任务管理，工作协调和解决问题的最佳实践。对于团队领导来说，可以消除工作障碍，帮团队更好地合作，取得更好的成果。

这部分的数据来自对所有 GitHub 活动（公有和私有，包括开源）项目的同比分析。比较的时间段是 2019 年 10 月 1 日至 2020 年 9 月 30 日与 2018 年 10 月 1 日至 2019 年 9 月 30 日。下图中包含了分析所包括的用户的地理分布年度变化。

开发者活跃度显著增加

本报告分析了每个账户的 pull request，push，review 过的 pull request 和评论过的 issue。总体而言，与去年同期相比，这些方面的数据均持平或有所增加。

除另有说明，图表中的数据均为以周为单位标准化后的每个开发者的数据。2019 年末的数据逢低与假期相对应。本报告对每个人每天的 pull request 和 push 量进行分析，发现与去年相比，活动持续增加。此外还分析了已 review 的 pull request 和已评论的 issue，得出的结论类似：数据高于去年，并且全年基本一致。

数据还表明，在 COVID-19 爆发和在家办公期间，数据一直保持一致，甚至有所增加。值得注意的是，虽然各种因素的冲击导致我们的工作方式发生了巨大变化，但相关数据却没有太大变动，这表明灵活的工具、流程和解决方案可以支撑开发者的工作效率，甚至可以在面临重大变化时持续创下新高。云开发能够为开发者提供更好的开发体验，为团队和组织提供更稳定，更具弹性的开发模式。此外，本报告还指出，灵活性对开发者来说也是很有好处的，可以让开发者通过将工作拆分开来完成。

合作是开发的重头戏

有些团队一直是远程工作，其中有全职团队也有开源项目团队，而有些团队则是不得不第一次施行远程工作。为了探究不断变化的工作环境会对关键的协作产生怎样的影响，本报告对 pull request 中的同行 review 的数据进行了分析。

Pull request 是开发者告知他人他们对仓库做了哪些更改的一种方式。一个 pull request 在合并前可能会涉及到一些感兴趣的开发者对改动进行 review，他们可能会检查所更改的内容，讨论代码，有时还会涉及到 commit。最后，pull request 会被合并到对应仓库的相关分支上。为了对此协作过程进行评估，本报告以 pull request 被创建到被合并所需时间为衡量指标，并与去年同期的数据进行了比较。

在开源代码仓库中，pull request 从被创建到被合并所需要的时间有所变化，大多数较大的波动发生在假期前后 —— 普遍来讲，今年的 pull request 合并所需时间从比上一年快 3.5 小时逐渐减慢到比上一年快 3 个小时。此外，在 2020 年 02 月中旬开始，合并 pull request 的速度变得比上一年更快，并且一直保持了下来，整体时间缩短了 1~7 个小时。

对于工作环境的代码进行分析发现，在 2019 年底，合并 pull request 的平均用时比上一年更长，团队仓库中的平均用时比上一年长 1.5 小时，企业账号中的平均用时比上一年长 1.5~4.2 小时。随着团队成员休假时间的增加（即假期），合并所需时间也会增加，并且 pull request 中 review 的量也会减少。

在 2020 年初，可以看到合并用时仍然比上一年更长，但有所改善：团队仓库的对应用时延长了 1-2 个小时，企业云仓库的对应用时延长了 0.1-1 小时。在三月份，合并 pull request 用时有一个大幅的下降，随后又有所延长，并且在今年其余时间一直保持了这种模式：团队仓库合并 pull request 的速度最快的时候提高了 5 个小时，而企业云仓库的速度提高了 6 个小时。

在近期的采访中，开发者和项目主管分享了他们团队使用 pull request 的经验。大家一致认同的最佳实践是，将 pull request 中的修改量控制在较低的水平，因为这样 review 起来更容易，也会促进review 的质量，如果出现了问题也更容易还原。此外，这还会增强正反馈，有助于提升大家创造的动力，提升团队的生产力。

Issue 创建量的变化

此外，报告中也对 GitHub 上 issue 的创建数量进行了分析。COVID-19 爆发前，GitHub 上每天创建的 issue 的数量少于或等于上一年同期。如图中箭头所示，这种情况在三月中旬开始发生转变，并在这次的整个分析期间一直保持了这种模式。同样，2020 年底的数据下降与假期相对应。

注意：GitHub 在 2020 年 4 月 14 日宣布了免费的团队账户，此报告也对相关数据进行了分析，来调查免费账户中的活动增长是由于账户政策的变化还是真正的活动增长。分析发现，活动数据的增长一半是 COVID-19 所引起的，因为在这一年中，免费账户的 issue 创建量有着明显的增长，并且这与企业账户的活动有着明显的不同。

进一步分析发现在所有仓库的 issue 创建增长率中都出现了类似的变化，其中增长最大的是免费开发者账户和付费团队账户所拥有的仓库。下图显示的是仓库中 issue 的创建量相对于去年同期的数据变化。可以注意到，11 月下旬企业云账户数据的高峰和低峰是美国感恩节假期所导致的。

开发并未受到影响

结合全球事件对数据进行分析，可以分成三个不同的阶段：10 月至 2019 年 12 月（COVID-19 之前），1 月至 2020 年 3 月（COVID 疫情初期），2020 年 4 月至 2020 年 9 月（大多数开发者开始转为在家工作）。从这个角度来看，分析发现企业账户和免费账户之间的 issue 的数据有所不同，尤其是 2020 年 4 月之后。

注意趋势线，从图中可以看出免费仓库的数据发生了巨大变化。

如果我们同样以这些日期范围进行划分，来对 push 和 pull request 进行分析，会发现在这一年中相关数据均略有增长，但活动没有什么明显的变化。因为 push 和 pull request 是开发活动的核心部分，因此工作地点的变化不会对它们产生太大的影响。

通过分析发现，即使开发者的工作量有所增加，但在过去的一年中，push 的实际大小（以每个 commit 中更改的文件数作为表征）仍大致相同。相反，issue 是用于跟踪和计划工作的，更容易受到干扰。

企业云仓库和 issue

企业云仓库的数据体现了两种主要的模式：到 2020 年 4 月，年同比数据相对稳定，之后总体数据有所下降。可以看到，在 4 月中旬和 5 月左右，issue 创建的活动激增，可能是因为开发者转为在家工作，所以通过 issue 协调开发工作。但是，报告并未看到 issue 的创建率恢复到上年同期水平。这可能是因为企业团队更习惯于通过 issue 来跟进开发。

免费仓库和 issue

免费仓库的数据也体现了两种主要的活动模式：到 2020 年 4 月，年同比数据相对稳定或略有降低。然后我们看到数据有一个巨大的涨幅，并似乎于 5 月份趋于平稳（4 月份至今的平均水平为 21%，中位数为 22%）。在免费仓库中，分析发现在周末 issue 的创建量并没有出现同样的大幅下降，这可能是因为与开源、业余爱好和教程等相关的活动。

自动化对开发有促进作用

通过自动化手段来快速可靠地交付代码非常重要。在写代码的时候能够快速得到反馈，来确认自己的代码可以部署对开发者非常重要，他们立即做下一个需求，而不是手动部署他们的代码。

本报告分析了开源代码库如何使用 Action 来自动处理其 pull request。重点研究 pull request 是因为它是开发过程中的关键交接点。通过在此阶段引入自动化，团队可以通知其他人对 pull request 进行 review，并在 review 完成后启动测试和构建。

在所有的开源代码库中，一旦其开始使用 Action，合并 pull request 的时间将减少 18%，合并的 pull request 的数量将增加 34%。在工作流程中使用自动化的团队能够加速其软件交付，因为他们可以更快地合并 pull request，更快地继续写代码，然后又可以将更多代码快速合并到他们的项目中。这是一个良性循环，优化了的软件开发实践，也为开发者提供了更好的体验，能够带来持续的收益。

自动化不仅可以加速软件交付。还有研究表明，自动化还可以减少错误提升提交的代码质量，这也使得开发者有更多的时间进行开发和创新。

行业标准

经常有人在问，开发者活动的“行业标准是什么”。GitHub 团队鼓励大家使用这些基准来考虑自己的编程实践，结合自己的实际情况，思考可以在哪些方面进行改进。

在工作和兴趣驱动的项目中，开发代码可能会有些不同，因此为了控制差异，在此仅分析了企业环境中的数据。在这种情况下：

开发者通常每天提交四次代码
Pull request 被创建到被合并通常需要 1.6 小时
代码 review 周期通常为 1 小时

在报告中，也将 pull request 和 review 的时间线拆分进行分析。可以看到，第一次 pull request review 通常需要 54 分钟，而从上一次review 到被合并的时间为 12 分钟。从 pull request 被创建到被合并用时为 1 小时 36 分钟。此外，在大多数情况下，pull request 中只有一人进行 review，因此在第一次 review 和最后一次 review 之间并没有消耗时间，但如果出现其他 review，则可能会导致延迟。

展望未来

本报告所分析的是一个自然发生的全球性“实验”，结果表明，远程工作比我们以前想象的要成功得多。仅在一年前宣布不可能施行远程工作的医疗行业，现在也找到了安全可靠的提供服务的方式，因为大环境要求他们必须这样。

本报告指出，GitHub 开发者的数量相比去年同期有所增长，与平台的典型增长情况一致，并且单个开发者的活动也有所增加。并且，在工作模式、公司战略、经济和市场大环境的不断变化下，还能有这样的数据增长是非常喜人的。这也表明基于云的开发为开发者、团队和组织提供了更稳定、更具弹性的开发。并且对工作时间和工作量的分析表明，开发者也从灵活性中获得了收益。灵活性可以让他们更灵活地安排自己的工作。

这是否会影响集中办公的模式？从报告中的研究结果，再加上对已经开始恢复工作的团队的研究表明：

团队可能会发现，最适合他们的工作模式是远程与实地相结合。
即使回到传统的工作场所后，我们发现工作时间仍然会更长。特别是“夜班”更加普遍。
提供灵活的解决方案，以便开发者可以创建适用于他们自己的解决方案，以使工作可持续。
网络条件和协作非常重要，即使有破坏性的事件出现，也不会造成过大的影响。

一年来的工作模式向我们表明，人们在做更多的工作，更多的事儿。这可能是人们使用了自动化对工作效率提升的结果，采用更优的开发实践以及工作和生活之间的界限更加模糊而实现的更加灵活的办公模式的结果。

我们都比我们所认为的更具可塑性。

致谢

作者: Nicole Forsgren

数据科学家: Greg Ceccarelli, Derek Jedamski, Scot Kelly, Clair Sullivan

审阅者: Denae Ford, Martin Fowler

文案编辑: Leah Clark, Cheryl Coupé, Stephanie Willis

设计师: Siobhán Doyle, Aja Shamblee

注明：本文基于 GitHub 2020 报告撰写，并非严格的翻译。你可以到掘金翻译计划下载本报告的中文译版，到 OCTOVERSE 下载英文原版。

微信搜索公众号「技术漫谈」，订阅更多精彩内容。