GitHub 2020 報(bào)告：全球開發(fā)者工作與生活平衡情況年度分析

GitHub 在 2020 年底發(fā)布了 2020 年社區(qū)和開發(fā)者報(bào)告^[1]。主要包括全球開發(fā)者工作與生活平衡情況，賦能社區(qū)健康和全球軟件安全報(bào)告三個(gè)部分，本文分享的是全球開發(fā)者工作與生活平衡情況，歡迎關(guān)注我訂閱其他部分的內(nèi)容。

前言

2020 年，由于疫情等因素的影響，很多企業(yè)和團(tuán)隊(duì)都被要求盡可能或者必須遠(yuǎn)程工作，因此很多開發(fā)者都轉(zhuǎn)成了遠(yuǎn)程工作，這也就要求他們必須重新思考其工作地點(diǎn)和時(shí)間安排，調(diào)整工作和家庭之間的界限 —— 我們可以看到或許也親身體會(huì)到，這件事兒其實(shí)并不簡(jiǎn)單。在本報(bào)告中，GitHub 官方對(duì)人們過去工作模式進(jìn)行了分析，來探求這種變化對(duì)開發(fā)者體驗(yàn)和生產(chǎn)力到底會(huì)產(chǎn)生怎樣的影響。

研究發(fā)現(xiàn)

通過詳細(xì)且嚴(yán)謹(jǐn)?shù)臄?shù)據(jù)分析，本報(bào)告指出以下四點(diǎn)發(fā)現(xiàn)：

1. 修改量小的 pull request 有助于推動(dòng)創(chuàng)新和生產(chǎn)力：嚴(yán)格將 pull request 的內(nèi)容修改量控制在較小范圍內(nèi)的團(tuán)隊(duì)，代碼審閱等相關(guān)的反饋速度更快。在過去的一年中，開發(fā)者們通過控制 pull request 中內(nèi)容的修改量，提升了他們工作的速度和質(zhì)量，并將 pull request 從創(chuàng)建到被合并所需時(shí)間控制在了七個(gè)半小時(shí)以內(nèi)。這樣大家就有更多的時(shí)間去做自己想做的事兒了。

2. 自動(dòng)化可以提升生產(chǎn)力，改善開發(fā)者體驗(yàn)：使用 GitHub 的 Action 來對(duì) pull request 進(jìn)行自動(dòng)化處理，使得其被合并所需時(shí)間縮短了 19%，并使得合并的 pull request 的數(shù)量提升了 34%。通過在工作流中使用自動(dòng)化工具，可以最大程度地降低手動(dòng)的操作，節(jié)省出更多的時(shí)間以讓團(tuán)隊(duì)成員進(jìn)行創(chuàng)新、開發(fā)和其他工作的協(xié)作。

3. 當(dāng)大家都在家時(shí)，開源是一種很好的“消遣”方式：數(shù)據(jù)分析表明，開發(fā)者在周末和假期會(huì)“離開”工作，而在這段時(shí)間開源項(xiàng)目的活躍度卻激增。這表明開發(fā)者對(duì)待工作和開源的態(tài)度是不一樣的，開發(fā)者可能會(huì)認(rèn)為開源是一個(gè)提供了學(xué)習(xí)、成長(zhǎng)、創(chuàng)新和與社區(qū)互動(dòng)的一個(gè)絕佳的渠道和機(jī)會(huì)。

4. 開發(fā)者活躍度凸顯了靈活和個(gè)性化解決方案的重要性：本報(bào)告通過分析了四大時(shí)區(qū)的開發(fā)活動(dòng)數(shù)據(jù)，發(fā)現(xiàn)在所有時(shí)區(qū)中，在過去的一年中，無論是工作時(shí)間還是工作量都在增加。并且開發(fā)者可能會(huì)通過靈活的時(shí)間安排來管理他們的時(shí)間和精力，這其實(shí)有助于延續(xù)他們的精力。但需要提醒的是，如果犧牲個(gè)人休息時(shí)間來工作，打破了工作和生活的平衡，那么長(zhǎng)遠(yuǎn)看來這種方式是沒法持續(xù)的。

工作建議

根據(jù)分析結(jié)果，本報(bào)告提出了以下四個(gè)建議：

1. 管理好個(gè)人精力：在家工作時(shí)做好工作管理的最好的方式之一就是管理好個(gè)人精力，計(jì)劃好核心工作的時(shí)間并完成對(duì)應(yīng)的工作，然后休息一下。利用間隙時(shí)間或者精力不是最集中的時(shí)間開會(huì)。這可以幫助你避免倦怠，避免厭惡工作。

2. 多嘗試，找到最適合自己的工作方式：人是很有韌性的。如果公司允許員工靈活安排工作時(shí)間，那么開發(fā)者就可以優(yōu)化自己的工作時(shí)間安排，管理他們的精力，在精力充沛的時(shí)間段完成所負(fù)責(zé)的工作。靈活的工具和工作流程也有助于提升團(tuán)隊(duì)的健壯性，無論大家在哪兒工作，都可以計(jì)劃、跟蹤并進(jìn)行開發(fā)。并且，將工具轉(zhuǎn)移到云上，也就是所謂的云開發(fā)，有助于提升開發(fā)體驗(yàn)。

3. 使用自動(dòng)化工具，并控制好 pull request 中的內(nèi)容修改量，有助于提升開發(fā)質(zhì)量和速度：因?yàn)檫@樣可以很好地減少一些手動(dòng)的操作，有助于提升代碼審閱的速度和質(zhì)量，也有助于提升開發(fā)效率，從而更快地交付開發(fā)。

4. 擁抱并支持協(xié)作和開源：大家對(duì)待開源的態(tài)度正在發(fā)生改變，在“離開”工作后，很多人會(huì)選擇通過做開源項(xiàng)目的方式來“消遣”。雖然可能還是在同一臺(tái)電腦上做著類似的事兒 ?。公司和組織應(yīng)該檢查自己的相關(guān)規(guī)定，盡量允許員工做開源項(xiàng)目。要認(rèn)識(shí)到，開源不僅是一個(gè)平臺(tái)，而是對(duì)員工來說至關(guān)重要的東西。

全球開發(fā)者什么時(shí)間工作，工作多久

開發(fā)者生產(chǎn)力有多個(gè)維度，包括解決復(fù)雜問題的能力，找到解決方案并完成需求等。而工作時(shí)長(zhǎng)和具體時(shí)間安排是生產(chǎn)力的一個(gè)方面，了解它有助于我們更好地安排自己的工作時(shí)間。

本報(bào)告此部分的數(shù)據(jù)來自滿足以下條件的付費(fèi)組織的賬戶：

1. 創(chuàng)建于 2018 年 10 月 01 日之前，至 2020 年 09 月之間，每個(gè)月都在活躍；
2. 付費(fèi)團(tuán)隊(duì)和企業(yè)云賬戶

為了便于進(jìn)行逐年比較，除另有說明，報(bào)告中所使用的數(shù)據(jù)均經(jīng)過歸一化處理。本報(bào)告分析了超過 35,0001 個(gè)組織的數(shù)據(jù)，其中北美 (41%)，歐洲 (35%) 和亞洲 (17%) 的代表最多。因此，本報(bào)告主要分析了全球四個(gè)時(shí)區(qū)的開發(fā)者工作模式：英國(guó)時(shí)區(qū)（UK Time Zone），美國(guó)東部時(shí)區(qū)（US Eastern Time Zone），美國(guó)太平洋時(shí)區(qū)（US Pacific Time Zone），日本標(biāo)準(zhǔn)時(shí)區(qū)（Japan Standard Time Zone）。

在過去的一年中，雖然 COVID-19 改變了大家的工作方式和工作地點(diǎn)，但是并沒有改變開發(fā)本身。在工作環(huán)境變化期間調(diào)查開發(fā)者生產(chǎn)力的最好的方式是，使用一種不會(huì)隨工作的變化而變化的指標(biāo)。而 GitHub 上的開發(fā)活動(dòng)是一個(gè)很好的指標(biāo)，即使工作發(fā)生了變化，該指標(biāo)也具有很好的魯棒性。盡管看板之類的東西可能已經(jīng)從白板轉(zhuǎn)移到了在線工具，但無論我們是在辦公室還是在家里，都可以通過相同的 push，pull request 和 issue 來觀察開發(fā)情況。這意味著本報(bào)告是比較可靠的。

GitHub 的數(shù)據(jù)沒辦法體現(xiàn)開發(fā)者在某段時(shí)間中的生產(chǎn)力高還是低，但我們可以觀察開發(fā)者的工作模式，以及這些模式隨時(shí)間的變化情況。這些開發(fā)工作模式并不能完全代表開發(fā)者的一天，它只能向我們展示開發(fā)者在開發(fā)部分所花費(fèi)的時(shí)間。因?yàn)殚_發(fā)者的工作并不僅僅是開發(fā)，還包括各種會(huì)議、計(jì)劃和處理郵件等工作。

但是，這些模式可能會(huì)讓我們對(duì)工作以及其中的變化產(chǎn)生一些新的啟發(fā)，尤其是今年這種大規(guī)模的遠(yuǎn)程工作的情況。通常在家工作的人，會(huì)在工作上花更多的時(shí)間 —— 每周加班時(shí)間超過 8-16 小時(shí)（Hill 等，2010）。這可能是因?yàn)槲覀兊墓ぷ餮由斓搅宋覀兊纳钪?，并且工作和生活之間的界限變得愈加模糊。隨著突然轉(zhuǎn)變?yōu)檫h(yuǎn)程工作，我們想知道是否會(huì)看到任何增加開發(fā)時(shí)間的模式。

在這些時(shí)區(qū)中，本報(bào)告同時(shí)分析了開發(fā)窗口（也就是工作時(shí)長(zhǎng)）和工作量。本報(bào)告選擇這些時(shí)區(qū)是因?yàn)樗鼈兙l(fā)布了較為強(qiáng)力的疫情管控措施，這可能有助于突顯工作模式所發(fā)生的變化。之所以選擇這些樣本，是因?yàn)楸緢?bào)告的樣本量足夠大，不會(huì)受到少數(shù)組織的過度影響，并且能夠獲得顯著的結(jié)果。

單個(gè)開發(fā)者的工作日工作時(shí)長(zhǎng)為其第一個(gè)到最后一個(gè) git push 之間的時(shí)間長(zhǎng)度，這被稱為“push 窗口”。這是對(duì)開發(fā)者開發(fā)窗口的開始和結(jié)束的一個(gè)粗略評(píng)估。

在此時(shí)間范圍內(nèi)，本報(bào)告按 push 次數(shù)計(jì)算工作量。注意，這里考慮的僅僅是開發(fā)工作，而開發(fā)只是開發(fā)者日常工作的一部分，很多其他工作任務(wù)，例如計(jì)劃、設(shè)計(jì)、會(huì)議和處理郵件等，并且可能會(huì)是在此窗口之外的時(shí)間進(jìn)行的。

全球概覽

• 在所有時(shí)區(qū)中，星期一的 push 窗口都相對(duì)較短，大多數(shù)工作時(shí)長(zhǎng)在 4.2 至 4.7 小時(shí)之間。
• 所有時(shí)區(qū)都在周六和周日工作，并且?guī)缀鹾椭芤坏墓ぷ鲿r(shí)長(zhǎng)相同。在周六，時(shí)間范圍為 3.7 至 4.3 小時(shí)。在周日，時(shí)間范圍為 3.7 至 5.4 小時(shí)。這可能是大家在趕上一周的需求，或者為下一周做準(zhǔn)備，也可能是開發(fā)者在做個(gè)人項(xiàng)目。
• 與其他時(shí)區(qū)相比，周二到周五，美國(guó)太平洋時(shí)區(qū)的 push 窗口明顯更長(zhǎng)，范圍為 8 小時(shí)至 8.3 小時(shí)。

本報(bào)告把所有時(shí)區(qū)每天的 push 次數(shù)進(jìn)行了對(duì)比分析，發(fā)現(xiàn)了一些有意思的現(xiàn)象：

• 在本報(bào)告研究的所有時(shí)區(qū)中，開發(fā)者一周七天都有活動(dòng)。
• 在所有時(shí)區(qū)中，日本標(biāo)準(zhǔn)時(shí)區(qū)中的人均 push 量最平衡，這是最可持續(xù)發(fā)展的工作方式。并且日本時(shí)區(qū)政府對(duì) COVID-19 的反應(yīng)也較為溫和，在這里雖然很早就支持了遠(yuǎn)程工作，但并不是強(qiáng)制的，隨意對(duì)工作流程的影響可能也沒有那么大。日本還是對(duì) COVID-19 最早也是相關(guān)管控的最好的國(guó)家之一，恢復(fù)正常工作的速度也相對(duì)較快。
• 與日本時(shí)區(qū)相反，美國(guó)太平洋時(shí)區(qū)的人均 push 量最高，這可能是加班文化（在這兒設(shè)有兩個(gè)核心的技術(shù)中心），或者是為了和其他跨多個(gè)時(shí)區(qū)的同時(shí)寫作導(dǎo)致的。但這種工作方式容易讓人厭倦工作，并不是可持續(xù)的工作模式。

英國(guó)時(shí)區(qū) push 窗口和工作量分析

首先，本報(bào)告對(duì)英國(guó)時(shí)區(qū)進(jìn)行分析，英國(guó)是最早發(fā)布居家隔離政策的國(guó)家之一。英國(guó)開發(fā)者在 2020 年 04 月之前的 push 窗 口與去年同期相比有所縮短，然而在三月中旬開始大幅增長(zhǎng)。從八月份開始，push 窗口開始趨于平穩(wěn)，并且相對(duì)于去年同期增長(zhǎng)了三分鐘。

觀察工作量，可以發(fā)現(xiàn)英國(guó)時(shí)區(qū)用戶的 push 量直到六月中旬才開始增加。并且直到八月和九月，其 push 量相較于去年同期都保持在了一個(gè)較高的水平。也就是說，英國(guó)時(shí)區(qū)的人們從六月開始工作時(shí)間更長(zhǎng)，工作量也更多了。

對(duì)英國(guó)時(shí)區(qū)開發(fā)者平均一周中的 push 窗口和工作量（平均 push 次數(shù)）進(jìn)行分析可以看出，在這個(gè)時(shí)區(qū)中：

• Push 窗口時(shí)長(zhǎng)大多為周五的 3.9 小時(shí)至周三的 4.4 小時(shí)之間。
• 工作量大多為周五的 13 次提交到周三的 15 次提交之間。
• 周六的 commit 量最高，高達(dá) 20 次。

周末 push 量的增加可能是由于周末提交代碼的開發(fā)者較少。但是還可能代表了個(gè)人工作量的升高，例如做開源項(xiàng)目，業(yè)余愛好或者教程等。因?yàn)樵诠ぷ魅臻_發(fā)者都在忙于工作相關(guān)的事兒，所以開發(fā)者會(huì)利用周末時(shí)間來做個(gè)人項(xiàng)目。值得注意的是，在除了日本標(biāo)準(zhǔn)時(shí)區(qū)以外的時(shí)區(qū)中均有類似的情況。稍會(huì)在分析該時(shí)區(qū)時(shí)對(duì)此進(jìn)行說明。

美國(guó)東部時(shí)區(qū) push 窗口和工作量分析

對(duì)于美國(guó)東海岸地區(qū)，開發(fā)者在 2020 年大部分時(shí)間的 push 窗口都相對(duì)較短，在 3 月份出現(xiàn)過上漲的情況，隨后在 8 月份開始趨于平穩(wěn)，相對(duì)去年同期增加了兩到三分鐘。11 月份數(shù)據(jù)下跌是因?yàn)楦卸鞴?jié)假期。

通過對(duì)此時(shí)區(qū)開發(fā)者的數(shù)據(jù)分析可以看出：

• 工作日 push 窗口范圍為星期一的 4.4 小 時(shí)至星期三的 5.3 小時(shí)。
• 工作量范圍為星期一的 12 個(gè) commit 到 星期三的 13 個(gè) commit。
• 星期日的 commit 量增加到最高，為 16 個(gè)。
• 開發(fā)者在周日的工作量和周一相當(dāng)，甚至更高。

美國(guó)太平洋時(shí)區(qū) push 窗口和工作量分析

通過分析可以看出，push 窗口長(zhǎng)度相對(duì)于去年同期有所變化，從三月中旬開始增加，普遍每周達(dá) 30 至 60 分鐘。這種情況一直持續(xù)到了六月，在七月初開始趨于平穩(wěn)。并且，在整個(gè)七月下旬相比去年同期增加了 5~7 分鐘，到八月再次下降。此外，11 月份的漲跌是感恩節(jié)假期導(dǎo)致的。

太平洋時(shí)區(qū)開發(fā)者的 push 量在今年全年始終高于去年。從五月份開始增加，在很多方面的活動(dòng)相較去年都增加超過了 50%，然后再九月份下降至高于去年 25% 的水平。本次調(diào)查通過代碼 push 情況可以看出在這一年中，太平洋時(shí)區(qū)相比于其他時(shí)區(qū)，開發(fā)者工作量一直是最高的。

在這個(gè)時(shí)區(qū)中：

• 工作日 push 窗口范圍為周一的 4.5 小時(shí)至周三的 8.3 小時(shí)。
• 每周的工作量從周一的 16 次 commit 到周三的 17 次 commit 不等。
• Commit 次數(shù)周日最高，為 23 次。

分析還發(fā)現(xiàn)了一個(gè)有趣的趨勢(shì)：企業(yè)開發(fā)者的活躍度在周末和節(jié)假日有所下降。但與此同時(shí)，開源項(xiàng)目的活躍度卻顯著提升，這表明大家在放下工作任務(wù)的時(shí)候轉(zhuǎn)而投向了開源。四月份以來，開源項(xiàng)目的創(chuàng)建量也同比增長(zhǎng)了 25%。尤其是在現(xiàn)在還有很多人是處于遠(yuǎn)程工作的狀態(tài)。開源使我們有機(jī)會(huì)進(jìn)行開發(fā)、創(chuàng)造、學(xué)習(xí)、合作以及與社區(qū)進(jìn)行分享。

日本時(shí)區(qū) push 窗口和工作量分析

最后，報(bào)告分析了日本標(biāo)準(zhǔn)時(shí)區(qū)。從 2019 年 11 月中旬開始，日本開發(fā)者的日工作時(shí)長(zhǎng)比去年同期有所增長(zhǎng)（提升了 5-15 分鐘）。從四月份開始，我們看到 push 窗口開始變得更長(zhǎng)，開發(fā)者開始每天在工作上多花費(fèi) 20-52 分鐘。六月份，該數(shù)據(jù)減少到比去年同期每天多花費(fèi) 15 分鐘左右。

在這個(gè)時(shí)區(qū)中：

• Push 窗口范圍為周五的 4.3小時(shí)至周二的 4.8 小時(shí)。
• 每周平均每個(gè)開發(fā)者每天的工作量為 9 次 commit。
• 周日工作量降為 8 次 commit。

與在美國(guó)和英國(guó)實(shí)施的封城等類似的封鎖措施不同，日本政府所采取的措施本質(zhì)上是非強(qiáng)制性的，對(duì)個(gè)人和企業(yè)沒有任何處罰。因此，工作模式轉(zhuǎn)變的影響可能并不顯著。

生產(chǎn)力人人有別

COVID-19 和突然開始遠(yuǎn)程工作的轉(zhuǎn)變?cè)斐闪撕艽蟮挠绊?。但是，開發(fā)者做的工作卻比去年同期更多。面對(duì)不確定性，生產(chǎn)率卻仍在提升，我們感到很高興，但這真的可持續(xù)嗎？對(duì)部分人來說，在家工作解放了生產(chǎn)力，他們可以根據(jù)自身的情況安排工作，按喜歡搭建工作環(huán)境，盡可能地降低干擾。并且，有更多的時(shí)間午休、鍛煉和陪伴家人。這在公司上班的時(shí)候是無法實(shí)現(xiàn)的，可能是由于開放式工作環(huán)境太嘈雜，或者辦公環(huán)境無法自定義，又或者通勤時(shí)間太長(zhǎng)，使得無法靈活地安排一天的時(shí)間。

但是，對(duì)于很多剛開始嘗試遠(yuǎn)程工作的人來說，可能會(huì)面臨很抓狂的情況。對(duì)于某些人來說，遠(yuǎn)程工作提升了與大家交往和溝通的難度。很多人家里也沒有工作區(qū)，缺少工作所需設(shè)備，還需要自己或者找人照顧孩子。工作和生活的界限會(huì)變得模糊，之前用于通勤的時(shí)間也變成了工作時(shí)間，導(dǎo)致工作時(shí)間變長(zhǎng)。盡管這樣，很多人還是會(huì)感覺時(shí)間不夠用，工作難按時(shí)完成。

在這分享幾個(gè)提交工作效率，避免怠倦的小技巧：

• 每天花幾分鐘想一想你所感激的事兒。有開發(fā)者分享說，這對(duì)他們的心態(tài)調(diào)整有著積極的作用。
• 除了管理你的時(shí)間，還要管理精力。找到適合自己的能夠維持較高工作效率的工作模式，并不斷針對(duì)這些模式進(jìn)行優(yōu)化。如果你喜歡早起，那就先完成重要的任務(wù)。如果你在下午或者晚上工作效率較高，那么就可以和其他同事協(xié)調(diào)好相關(guān)工作。
• 作為團(tuán)隊(duì)，應(yīng)該支持靈活、可持續(xù)的工作時(shí)間安排，并注意團(tuán)隊(duì)成員的倦怠現(xiàn)象。這有助于使我們的團(tuán)隊(duì)和我們自身工作得更開心，更有生產(chǎn)力。

更多有關(guān)在家工作的小技巧，請(qǐng)查看以下資料：

• 遠(yuǎn)程工作：COVID-19 期間，父母?jìng)兪侨绾芜m應(yīng)遠(yuǎn)程工作的^[2]
• 遠(yuǎn)程工作：遠(yuǎn)程如何協(xié)作工作^[3]
• 播客：父母驅(qū)動(dòng)遠(yuǎn)程工作^[4]

開發(fā)者活動(dòng)

開發(fā)者活動(dòng)（也就是開發(fā)者行為）是生產(chǎn)力的另一個(gè)方面。將開發(fā)者活動(dòng)作為生產(chǎn)力的一部分來衡量是十分復(fù)雜的，但如果做得好，也很有益處。這可以幫助開發(fā)者揭示任務(wù)管理，工作協(xié)調(diào)和解決問題的最佳實(shí)踐。對(duì)于團(tuán)隊(duì)領(lǐng)導(dǎo)來說，可以消除工作障礙，幫團(tuán)隊(duì)更好地合作，取得更好的成果。

這部分的數(shù)據(jù)來自對(duì)所有 GitHub 活動(dòng)（公有和私有，包括開源）項(xiàng)目的同比分析。比較的時(shí)間段是 2019 年 10 月 1 日至 2020 年 9 月 30 日與 2018 年 10 月 1 日至 2019 年 9 月 30 日。下圖中包含了分析所包括的用戶的地理分布年度變化。

開發(fā)者活躍度顯著增加

本報(bào)告分析了每個(gè)賬戶的 pull request，push，review 過的 pull request 和評(píng)論過的 issue?？傮w而言，與去年同期相比，這些方面的數(shù)據(jù)均持平或有所增加。

除另有說明，圖表中的數(shù)據(jù)均為以周為單位標(biāo)準(zhǔn)化后的每個(gè)開發(fā)者的數(shù)據(jù)。2019 年末的數(shù)據(jù)逢低與假期相對(duì)應(yīng)。本報(bào)告對(duì)每個(gè)人每天的 pull request 和 push 量進(jìn)行分析，發(fā)現(xiàn)與去年相比，活動(dòng)持續(xù)增加。此外還分析了已 review 的 pull request 和已評(píng)論的 issue，得出的結(jié)論類似：數(shù)據(jù)高于去年，并且全年基本一致。

數(shù)據(jù)還表明，在 COVID-19 爆發(fā)和在家辦公期間，數(shù)據(jù)一直保持一致，甚至有所增加。值得注意的是，雖然各種因素的沖擊導(dǎo)致我們的工作方式發(fā)生了巨大變化，但相關(guān)數(shù)據(jù)卻沒有太大變動(dòng)，這表明靈活的工具、流程和解決方案可以支撐開發(fā)者的工作效率，甚至可以在面臨重大變化時(shí)持續(xù)創(chuàng)下新高。云開發(fā)能夠?yàn)殚_發(fā)者提供更好的開發(fā)體驗(yàn)，為團(tuán)隊(duì)和組織提供更穩(wěn)定，更具彈性的開發(fā)模式。此外，本報(bào)告還指出，靈活性對(duì)開發(fā)者來說也是很有好處的，可以讓開發(fā)者通過將工作拆分開來完成。

合作是開發(fā)的重頭戲

有些團(tuán)隊(duì)一直是遠(yuǎn)程工作，其中有全職團(tuán)隊(duì)也有開源項(xiàng)目團(tuán)隊(duì)，而有些團(tuán)隊(duì)則是不得不第一次施行遠(yuǎn)程工作。為了探究不斷變化的工作環(huán)境會(huì)對(duì)關(guān)鍵的協(xié)作產(chǎn)生怎樣的影響，本報(bào)告對(duì) pull request 中的同行 review 的數(shù)據(jù)進(jìn)行了分析。

Pull request 是開發(fā)者告知他人他們對(duì)倉(cāng)庫(kù)做了哪些更改的一種方式。一個(gè) pull request 在合并前可能會(huì)涉及到一些感興趣的開發(fā)者對(duì)改動(dòng)進(jìn)行 review，他們可能會(huì)檢查所更改的內(nèi)容，討論代碼，有時(shí)還會(huì)涉及到 commit。最后，pull request 會(huì)被合并到對(duì)應(yīng)倉(cāng)庫(kù)的相關(guān)分支上。為了對(duì)此協(xié)作過程進(jìn)行評(píng)估，本報(bào)告以 pull request 被創(chuàng)建到被合并所需時(shí)間為衡量指標(biāo)，并與去年同期的數(shù)據(jù)進(jìn)行了比較。

在開源代碼倉(cāng)庫(kù)中，pull request 從被創(chuàng)建到被合并所需要的時(shí)間有所變化，大多數(shù)較大的波動(dòng)發(fā)生在假期前后 —— 普遍來講，今年的 pull request 合并所需時(shí)間從比上一年快 3.5 小時(shí)逐漸減慢到比上一年快 3 個(gè)小時(shí)。此外，在 2020 年 02 月中旬開始，合并 pull request 的速度變得比上一年更快，并且一直保持了下來，整體時(shí)間縮短了 1~7 個(gè)小時(shí)。

對(duì)于工作環(huán)境的代碼進(jìn)行分析發(fā)現(xiàn)，在 2019 年底，合并 pull request 的平均用時(shí)比上一年更長(zhǎng)，團(tuán)隊(duì)倉(cāng)庫(kù)中的平均用時(shí)比上一年長(zhǎng) 1.5 小時(shí)，企業(yè)賬號(hào)中的平均用時(shí)比上一年長(zhǎng) 1.5~4.2 小時(shí)。隨著團(tuán)隊(duì)成員休假時(shí)間的增加（即假期），合并所需時(shí)間也會(huì)增加，并且 pull request 中 review 的量也會(huì)減少。

在 2020 年初，可以看到合并用時(shí)仍然比上一年更長(zhǎng)，但有所改善：團(tuán)隊(duì)倉(cāng)庫(kù)的對(duì)應(yīng)用時(shí)延長(zhǎng)了 1~2 個(gè)小時(shí)，企業(yè)云倉(cāng)庫(kù)的對(duì)應(yīng)用時(shí)延 長(zhǎng)了 0.1~1 小時(shí)。在三月份，合并 pull request 用時(shí)有一個(gè)大幅的下降，隨后又有所延長(zhǎng)，并且在今年其余時(shí)間一直保持了這種模式：團(tuán)隊(duì)倉(cāng)庫(kù)合并 pull request 的速度最快的時(shí)候提高了 5 個(gè)小時(shí)，而企業(yè)云倉(cāng)庫(kù)的速度提高了 6 個(gè)小時(shí)。

在 近期的采訪中^[5]，開發(fā)者和項(xiàng)目主管分享了他們團(tuán)隊(duì)使用 pull request 的經(jīng)驗(yàn)。大家一致認(rèn)同的最佳實(shí)踐是，將 pull request 中的修改量控制在較低的水平，因?yàn)檫@樣 review 起來更容易，也會(huì)促進(jìn)review 的質(zhì)量，如果出現(xiàn)了問題也更容易還原。此外，這還會(huì)增強(qiáng)正反饋，有助于提升大家創(chuàng)造的動(dòng)力，提升團(tuán)隊(duì)的生產(chǎn)力。

Issue 創(chuàng)建量的變化

此外，報(bào)告中也對(duì) GitHub 上 issue 的創(chuàng)建數(shù)量進(jìn)行了分析。COVID-19 爆發(fā)前，GitHub 上每天創(chuàng)建的 issue 的數(shù)量少于或等于上一年同期。如圖中箭頭所示，這種情況在三月中旬開始發(fā)生轉(zhuǎn)變，并在這次的整個(gè)分析期間一直保持了這種模式。同樣，2020 年底的數(shù)據(jù)下降與假期相對(duì)應(yīng)。

注意：GitHub 在 2020 年 4 月 14 日宣布了免費(fèi)的團(tuán)隊(duì)賬戶，此報(bào)告也對(duì)相關(guān)數(shù)據(jù)進(jìn)行了分析，來調(diào)查免費(fèi)賬戶中的 活動(dòng)增長(zhǎng)是由于賬戶政策的變化還是真正的活動(dòng)增長(zhǎng)。分析發(fā)現(xiàn)，活動(dòng)數(shù)據(jù)的增長(zhǎng)一半是 COVID-19 所引起的， 因?yàn)樵谶@一年中，免費(fèi)賬戶的 issue 創(chuàng)建量有著明顯的增長(zhǎng)，并且這與企業(yè)賬戶的活動(dòng)有著明顯的不同。

進(jìn)一步分析發(fā)現(xiàn)在所有倉(cāng)庫(kù)的 issue 創(chuàng)建增長(zhǎng)率中都出現(xiàn)了類似的變化，其中增長(zhǎng)最大的是免費(fèi)開發(fā)者賬戶和付費(fèi)團(tuán)隊(duì)賬戶所擁有的倉(cāng)庫(kù)。下圖顯示的是倉(cāng)庫(kù)中 issue 的創(chuàng)建量相對(duì)于去年同期的數(shù)據(jù)變化?？梢宰⒁獾?，11 月下旬企業(yè)云賬戶數(shù)據(jù)的高峰和低峰是美國(guó)感恩節(jié)假期所導(dǎo)致的。

開發(fā)并未受到影響

結(jié)合全球事件對(duì)數(shù)據(jù)進(jìn)行分析，可以分成三個(gè)不同的階段：10 月至 2019 年 12 月（COVID-19 之前），1 月至 2020 年 3 月（COVID 疫情初期），2020 年 4 月至 2020 年 9 月（大多數(shù)開發(fā)者開始轉(zhuǎn)為在家工作）。從這個(gè)角度來看，分析發(fā)現(xiàn)企業(yè)賬戶和免費(fèi)賬戶之間的 issue 的數(shù)據(jù)有所不同，尤其是 2020 年 4 月之后。

注意趨勢(shì)線，從圖中可以看出免費(fèi)倉(cāng)庫(kù)的數(shù)據(jù)發(fā)生了巨大變化。

如果我們同樣以這些日期范圍進(jìn)行劃分，來對(duì) push 和 pull request 進(jìn)行分析，會(huì)發(fā)現(xiàn)在這一年中相關(guān)數(shù)據(jù)均略有增長(zhǎng)，但活動(dòng)沒有什么明顯的變化。因?yàn)?push 和 pull request 是開發(fā)活動(dòng)的核心部分，因此工作地點(diǎn)的變化不會(huì)對(duì)它們產(chǎn)生太大的影響。

通過分析發(fā)現(xiàn)，即使開發(fā)者的工作量有所增加，但在過去的一年中，push 的實(shí)際大?。ㄒ悦總€(gè) commit 中更改的文件數(shù) 作為表征）仍大致相同。相反，issue 是用于跟蹤和計(jì)劃工作的，更容易受到干擾。

企業(yè)云倉(cāng)庫(kù)和 issue

企業(yè)云倉(cāng)庫(kù)的數(shù)據(jù)體現(xiàn)了兩種主要的模式：到 2020 年 4 月，年同比數(shù)據(jù)相對(duì)穩(wěn)定，之后總體數(shù)據(jù)有所下降?？梢钥吹剑?4 月中旬和 5 月左右，issue 創(chuàng)建的活動(dòng)激增，可能是因?yàn)殚_發(fā)者轉(zhuǎn)為在家工作，所以通過 issue 協(xié)調(diào)開發(fā)工作。但是，報(bào)告并未看到 issue 的創(chuàng)建率恢復(fù)到上年同期水平。這可能是因?yàn)槠髽I(yè)團(tuán)隊(duì)更習(xí)慣于通過 issue 來跟進(jìn)開發(fā)。

免費(fèi)倉(cāng)庫(kù)和 issue

免費(fèi)倉(cāng)庫(kù)的數(shù)據(jù)也體現(xiàn)了兩種主要的活動(dòng)模式：到 2020 年 4 月，年同比數(shù)據(jù)相對(duì)穩(wěn)定或略有降低。然后我們看到數(shù)據(jù)有一個(gè)巨大的漲幅，并似乎于 5 月份趨于平穩(wěn)（4 月份至今的平均水平為 21%，中位數(shù)為 22%）。在免費(fèi)倉(cāng)庫(kù)中，分析發(fā)現(xiàn)在周末 issue 的創(chuàng)建量并沒有出現(xiàn)同樣的大幅下降，這可能是因?yàn)榕c開源、業(yè)余愛好和教程等相關(guān)的活動(dòng)。

自動(dòng)化對(duì)開發(fā)有促進(jìn)作用

通過自動(dòng)化手段來快速可靠地交付代碼非常重要。在寫代碼的時(shí)候能夠快速得到反饋，來確認(rèn)自己的代碼可以部署對(duì)開發(fā)者非常重要，他們立即做下一個(gè)需求，而不是手動(dòng)部署他們的代碼。

本報(bào)告分析了開源代碼庫(kù)如何使用 Action 來自動(dòng)處理其 pull request。重點(diǎn)研究 pull request 是因?yàn)樗情_發(fā)過程中的關(guān)鍵交接點(diǎn)。通過在此階段引入自動(dòng)化，團(tuán)隊(duì)可以通知其他人對(duì) pull request 進(jìn)行 review，并在 review 完成后啟動(dòng)測(cè)試和構(gòu)建。

在所有的開源代碼庫(kù)中，一旦其開始使用 Action，合并 pull request 的時(shí)間將減少 18%，合并的 pull request 的數(shù)量將增加 34%。在工作流程中使用自動(dòng)化的團(tuán)隊(duì)能夠加速其軟件交付，因?yàn)樗麄兛梢愿斓睾喜?pull request，更快地繼續(xù)寫代碼，然后又可以將更多代碼快速合并到他們的項(xiàng)目中。這是一個(gè)良性循環(huán)，優(yōu)化了的軟件開發(fā)實(shí)踐，也為開發(fā)者提供了更好的體驗(yàn)，能夠帶來持續(xù)的收益。

自動(dòng)化不僅可以加速軟件交付。還有研究表明，自動(dòng)化還可以減少錯(cuò)誤提升提交的代碼質(zhì)量，這也使得開發(fā)者有更多的時(shí)間進(jìn)行開發(fā)和創(chuàng)新。

行業(yè)標(biāo)準(zhǔn)

經(jīng)常有人在問，開發(fā)者活動(dòng)的“行業(yè)標(biāo)準(zhǔn)是什么”。GitHub 團(tuán)隊(duì)鼓勵(lì)大家使用這些基準(zhǔn)來考慮自己的編程實(shí)踐，結(jié)合自己的實(shí)際情況，思考可以在哪些方面進(jìn)行改進(jìn)。

在工作和興趣驅(qū)動(dòng)的項(xiàng)目中，開發(fā)代碼可能會(huì)有些不同，因此為了控制差異，在此僅分析了企業(yè)環(huán)境中的數(shù)據(jù)。在這種情況下：

• 開發(fā)者通常每天提交四次代碼
• Pull request 被創(chuàng)建到被合并通常需要 1.6 小時(shí)
• 代碼 review 周期通常為 1 小時(shí)

在報(bào)告中，也將 pull request 和 review 的時(shí)間線拆分進(jìn)行分析。可以看到，第一次 pull request review 通常需要 54 分鐘，而從上一次review 到被合并的時(shí)間為 12 分鐘。從 pull request 被創(chuàng)建到被合并用時(shí)為 1 小時(shí) 36 分鐘。此外，在大多數(shù)情況下，pull request 中只有一人進(jìn)行 review，因此在第一次 review 和最后一次 review 之間并沒有消耗時(shí)間，但如果出現(xiàn)其他 review，則可能會(huì)導(dǎo)致延遲。

展望未來

本報(bào)告所分析的是一個(gè)自然發(fā)生的全球性“實(shí)驗(yàn)”，結(jié)果表明，遠(yuǎn)程工作比我們以前想象的要成功得多。僅在一年前宣布不可能施行遠(yuǎn)程工作的醫(yī)療行業(yè)，現(xiàn)在也找到了安全可靠的提供服務(wù)的方式，因?yàn)榇蟓h(huán)境要求他們必須這樣。

本報(bào)告指出，GitHub 開發(fā)者的數(shù)量相比去年同期有所增長(zhǎng)，與平臺(tái)的典型增長(zhǎng)情況一致，并且單個(gè)開發(fā)者的活動(dòng)也有所增加。并且，在工作模式、公司戰(zhàn)略、經(jīng)濟(jì)和市場(chǎng)大環(huán)境的不斷變化下，還能有這樣的數(shù)據(jù)增長(zhǎng)是非常喜人的。這也表明基于云的開發(fā)為開發(fā)者、團(tuán)隊(duì)和組織提供了更穩(wěn)定、更具彈性的開發(fā)。并且對(duì)工作時(shí)間和工作量的分析表明，開發(fā)者也從靈活性中獲得了收益。靈活性可以讓他們更靈活地安排自己的工作。

這是否會(huì)影響集中辦公的模式？從報(bào)告中的研究結(jié)果，再加上對(duì)已經(jīng)開始恢復(fù)工作的團(tuán)隊(duì)的研究表明：

• 團(tuán)隊(duì)可能會(huì)發(fā)現(xiàn)，最適合他們的工作模式是遠(yuǎn)程與實(shí)地相結(jié)合。
• 即使回到傳統(tǒng)的工作場(chǎng)所后，我們發(fā)現(xiàn)工作時(shí)間仍然會(huì)更長(zhǎng)。特別是“夜班”更加普遍。
• 提供靈活的解決方案，以便開發(fā)者可以創(chuàng)建適用于他們自己的解決方案，以使工作可持續(xù)。
• 網(wǎng)絡(luò)條件和協(xié)作非常重要，即使有破壞性的事件出現(xiàn)，也不會(huì)造成過大的影響。

一年來的工作模式向我們表明，人們?cè)谧龈嗟墓ぷ?，更多的事兒。這可能是人們使用了自動(dòng)化對(duì)工作效率提升的結(jié)果，采用更優(yōu)的開發(fā)實(shí)踐以及工作和生活之間的界限更加模糊而實(shí)現(xiàn)的更加靈活的辦公模式的結(jié)果。

我們都比我們所認(rèn)為的更具可塑性。

致謝

• 作者: Nicole Forsgren
• 數(shù)據(jù)科學(xué)家: Greg Ceccarelli, Derek Jedamski, Scot Kelly, Clair Sullivan
• 審閱者: Denae Ford, Martin Fowler
• 文案編輯: Leah Clark, Cheryl Coupé, Stephanie Willis
• 設(shè)計(jì)師: Siobhán Doyle, Aja Shamblee

注明：本文基于 GitHub 2020 報(bào)告^[6] 撰寫，并非嚴(yán)格的翻譯。在本公眾號(hào)后臺(tái)回復(fù)關(guān)鍵字「202001」即可獲取本報(bào)告的原版和中文譯版。

微信搜索公眾號(hào)「技術(shù)漫談」，訂閱更多精彩內(nèi)容。

參考資料