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

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

前言

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

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

通過詳細且嚴謹?shù)臄?shù)據(jù)分析，本報告指出以下四點發(fā)現(xiàn)：

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

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

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

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

工作建議

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

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

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

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

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

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

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

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

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

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

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

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

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

在這些時區(qū)中，本報告同時分析了開發(fā)窗口（也就是工作時長）和工作量。本報告選擇這些時區(qū)是因為它們均發(fā)布了較為強力的疫情管控措施，這可能有助于突顯工作模式所發(fā)生的變化。之所以選擇這些樣本，是因為本報告的樣本量足夠大，不會受到少數(shù)組織的過度影響，并且能夠獲得顯著的結(jié)果。

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

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

全球概覽

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在這個時區(qū)中：

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

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

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

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

在這個時區(qū)中：

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

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

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

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

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

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

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

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

• 遠程工作：COVID-19 期間，父母們是如何適應(yīng)遠程工作的^[2]
• 遠程工作：遠程如何協(xié)作工作^[3]
• 播客：父母驅(qū)動遠程工作^[4]

開發(fā)者活動

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

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

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

本報告分析了每個賬戶的 pull request，push，review 過的 pull request 和評論過的 issue。總體而言，與去年同期相比，這些方面的數(shù)據(jù)均持平或有所增加。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

企業(yè)云倉庫和 issue

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

免費倉庫和 issue

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

自動化對開發(fā)有促進作用

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

本報告分析了開源代碼庫如何使用 Action 來自動處理其 pull request。重點研究 pull request 是因為它是開發(fā)過程中的關(guān)鍵交接點。通過在此階段引入自動化，團隊可以通知其他人對 pull request 進行 review，并在 review 完成后啟動測試和構(gòu)建。

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

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

行業(yè)標準

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

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

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

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

展望未來

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

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

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

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

一年來的工作模式向我們表明，人們在做更多的工作，更多的事兒。這可能是人們使用了自動化對工作效率提升的結(jié)果，采用更優(yōu)的開發(fā)實踐以及工作和生活之間的界限更加模糊而實現(xiàn)的更加靈活的辦公模式的結(jié)果。

我們都比我們所認為的更具可塑性。

致謝

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

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

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

參考資料