Отчет GitHub 2020: глобальный баланс между работой и личной жизнью разработчиков

GitHub выпущен в конце 2020 г.Отчет сообщества и разработчиков за 2020 г.. В основном он состоит из трех частей: баланс работы и личной жизни глобальных разработчиков, укрепление здоровья сообщества и глобальный отчет о безопасности программного обеспечения. В этой статье рассказывается о балансе между работой и личной жизнью глобальных разработчиков. Подпишитесь на меня, чтобы подписаться на другие части контента.

предисловие

В 2020 году из-за воздействия эпидемии и других факторов многие компании и команды вынуждены работать удаленно как можно больше или должны, поэтому многие разработчики перешли на удаленную работу, что также требует от них переосмысления мест работы и графиков. , Регулировка границ между работой и домом — как мы можем видеть и, возможно, испытать на собственном опыте, — непростая задача. В этом отчете официальные лица GitHub анализируют прошлые модели работы людей, чтобы выяснить, как это изменение повлияет на опыт и производительность разработчиков.

Исследование показало

Благодаря подробному и тщательному анализу данных в этом отчете отмечаются следующие четыре вывода:

Запросы на вытягивание с небольшими изменениями помогают стимулировать инновации и производительность.: Команды, которые строго контролируют количество модификаций контента запроса на включение в небольшом диапазоне, обратная связь, связанная с проверкой кода и т. д., быстрее. За последний год разработчики улучшили скорость и качество своей работы, контролируя количество изменений в пул-реквестах, и сократили время создания пулл-реквестов до слияния менее чем за семь с половиной часов. Это даст каждому больше времени, чтобы делать то, что он хочет.
Автоматизация может повысить производительность и улучшить опыт разработчиков: Использование GitHub Actions для автоматизации обработки запросов на вытягивание сократило время, необходимое для слияния, на 19 % и увеличило количество объединенных запросов на вытягивание на 34 %. Используя автоматизированные инструменты в рабочем процессе, можно свести к минимуму ручные действия и сэкономить больше времени для совместной работы членов команды над инновациями, разработками и другой работой.
Открытый исходный код — отличный способ сделать «паузу», когда все дома.: Анализ данных показывает, что разработчики «оставляют» свою работу на выходные и праздничные дни, а активность проектов с открытым исходным кодом в это время резко возросла. Это показывает, что разработчики по-разному относятся к работе и открытым исходным кодам, и разработчики могут рассматривать открытый исходный код как отличный канал и возможность учиться, расти, внедрять инновации и взаимодействовать с сообществом.
Активность разработчиков подчеркивает важность гибких и персонализированных решений: в этом отчете анализируются данные о деятельности по разработке в четырех основных часовых поясах и делается вывод о том, что во всех часовых поясах количество часов и рабочих нагрузок увеличилось за последний год. И разработчики могут управлять своим временем и энергией с помощью гибких графиков, которые на самом деле помогают поддерживать их энергию. Но имейте в виду, что если вы пожертвуете личным временем ради работы и нарушите баланс между работой и личной жизнью, это не будет устойчивым в долгосрочной перспективе.

совет по работе

На основании результатов анализа в настоящем отчете даются следующие четыре рекомендации:

Управляйте личной энергией: один из лучших способов управлять своей работой во время работы из дома — это управлять своей энергией, планировать свое время для основной работы и выполнять ее, а затем делать перерыв. Используйте время перерыва или время, когда ваша энергия не наиболее сконцентрирована для встреч. Это может помочь вам избежать выгорания и отвращения к работе.
Экспериментируйте и найдите способ, который лучше всего подходит для вас: Люди очень устойчивы. Если компании позволяют сотрудникам работать гибко, разработчики могут оптимизировать свои графики работы, управлять своей энергией и выполнять свою работу в периоды высокой энергии. Гибкие инструменты и рабочие процессы также способствуют надежности команды, что позволяет всем планировать, тратить и развивать развитие везде, где они работают. И, движущиеся инструменты в облако, известные как развитие облака, могут помочь улучшить опыт развития.
Использование автоматизированных инструментов и контроль количества модификаций контента в запросах на включение может помочь улучшить качество и скорость разработки.: потому что это может значительно сократить количество ручных операций, помочь повысить скорость и качество проверки кода, а также помочь повысить эффективность разработки, чтобы разработка могла выполняться быстрее.
Примите и поддержите совместную работу и открытый исходный код: Отношение всех к открытому исходному коду меняется.После «ухода» с работы многие люди предпочитают «развлекаться», делая проекты с открытым исходным кодом. Хотя наверное до сих пор делаю что-то подобное на том же компе 😂. Компании и организации должны проверить свои собственные правила и попытаться разрешить сотрудникам работать над проектами с открытым исходным кодом. Признайте, что открытый исходный код — это не просто платформа, а то, что важно для сотрудников.

Когда и как долго работают глобальные разработчики

Продуктивность разработчика имеет несколько измерений, включая способность решать сложные проблемы, находить решения и выполнять требования и т. д. Хотя рабочее время и конкретные графики являются одним из аспектов продуктивности, понимание этого помогает нам лучше организовать свое рабочее время.

Данные в этом разделе отчета взяты со счетов платежных организаций, отвечающих следующим критериям:

Создан до 01 октября 2018 года и активируется каждый месяц между сентября 2020 года;
Платные учетные записи Team и Enterprise Cloud

Для облегчения сравнения по годам, если не указано иное, данные, используемые в отчете, нормализованы. В этом отчете анализируются данные из более чем 35 0001 организаций, из которых наиболее представлены Северная Америка (41%), Европа (35%) и Азия (17%). Поэтому в этом отчете в основном анализируется режим работы разработчиков в четырех часовых поясах по всему миру: часовой пояс Великобритании, восточный часовой пояс США, тихоокеанский часовой пояс США и стандартный часовой пояс Японии (Стандартный часовой пояс).

Хотя за последний год COVID-19 изменил то, как и где мы работаем, саму разработку он не изменил. Лучший способ исследовать производительность разработчика в меняющейся рабочей среде — использовать показатель, который не меняется вместе с работой. А активность разработчиков на GitHub — хороший показатель, который очень надежен, даже если работа меняется. В то время как такие вещи, как Kanban, возможно, переместились с досок в онлайн-инструменты, одни и те же push-уведомления, запросы на вытягивание и задачи можно использовать для наблюдения за разработкой, где бы мы ни находились — в офисе или дома. Это означает, что этот отчет является относительно надежным.

Данные GitHub не могут сказать, были ли разработчики продуктивными или непродуктивными с течением времени, но мы можем наблюдать шаблоны работы разработчиков и то, как эти шаблоны меняются с течением времени. Эти шаблоны работы по разработке не полностью отражают день разработчика, они только показывают нам, сколько времени разработчик тратит на разработку. Потому что работа разработчика — это не только разработка, но и различные встречи, планирование и обработка писем.

Но эти шаблоны могут пролить свет на работу и изменения в ней, особенно в связи с масштабной удаленной работой в этом году. Люди, которые обычно работают из дома, проводят больше времени на работе — более 8–16 часов сверхурочной работы в неделю (Hill et al., 2010). Это может быть связано с тем, что наша работа распространяется на нашу жизнь, и границы между работой и жизнью становятся все более размытыми. С внезапным переходом на удаленную работу мы задались вопросом, увидим ли мы какую-либо закономерность увеличения времени разработки.

В этих часовых поясах в этом отчете анализируются как окна разработки (т. е. рабочие часы), так и рабочая нагрузка. Эти часовые пояса были выбраны для этого отчета, потому что в них приняты более строгие меры по сдерживанию распространения вируса, что может помочь выявить изменения в схемах работы. Эти образцы были выбраны потому, что размер выборки для этого отчета достаточно велик, чтобы не подвергаться чрезмерному влиянию небольшого количества тканей и иметь возможность получить значимые результаты.

Один рабочий день разработчика — это промежуток времени между первым и последним git push, известный как «окно push». Это приблизительная оценка начала и конца окна разработки разработчика.

В течение этого времени в этом отчете рассчитывается рабочая нагрузка по PUSH. Обратите внимание, что это только развитие разработки, в то время как разработка является лишь частью повседневной работы разработчиков, многие другие рабочие задачи, такие как планы, дизайн, конференции, обработка электронной почты и т. д., могут быть за пределами этого окна.

Общий обзор

Окно push-уведомлений в понедельник было относительно коротким во всех часовых поясах, и большинство вакансий длилось от 4,2 до 4,7 часов.
Все часовые пояса работают по субботам и воскресеньям и работают почти в те же часы, что и понедельники. По субботам диапазон времени составляет от 3,7 до 4,3 часов. По воскресеньям временной диапазон составляет от 3,7 до 5,4 часов. Это могут быть люди, догоняющие потребности одной недели, или готовящиеся к следующей неделе, или это может быть разработчик, работающий над личным проектом.
Пуш-окно в тихоокеанском часовом поясе США значительно длиннее со вторника по пятницу по сравнению с другими часовыми поясами и составляет от 8 до 8,3 часов.

В этом отчете сравнивается и анализируется количество пушей в день во всех часовых поясах и обнаруживаются некоторые интересные явления:

Разработчики активны семь дней в неделю во всех часовых поясах, изученных для этого отчета.
Из всех часовых поясов в стандартном часовом поясе Японии наиболее сбалансирована нагрузка на душу населения, что является наиболее устойчивым способом работы. И правительство часовых поясов Японии также более мягко отреагировало на COVID-19, где удаленная работа поддерживалась на раннем этапе, но не была обязательной, и влияние на рабочий процесс может быть не таким большим. Япония также является одной из первых и лучших стран для борьбы с COVID-19, и возвращение к нормальной работе происходит относительно быстро.
В отличие от японского часового пояса, в тихоокеанском часовом поясе США самый высокий объем толчков на душу населения, что может быть связано с культурой сверхурочной работы (здесь есть два основных технических центра) или с необходимостью писать одновременно с другими в разных часовых поясах. Но при таком способе работы легко устать, и это не устойчивая модель работы.

Push-окно часового пояса Великобритании и анализ рабочей нагрузки

Во-первых, в этом отчете анализируется часовой пояс Соединенного Королевства, одной из первых стран, принявших политику самоизоляции. Пуш-окно для британских разработчиков до апреля 2020 года сократилось по сравнению с аналогичным периодом прошлого года, но в середине марта начало значительно увеличиваться. Начиная с августа, пуш-окно начало выравниваться и выросло на три минуты по сравнению с аналогичным периодом прошлого года.

Глядя на рабочую нагрузку, можно увидеть, что количество пушей от пользователей в часовом поясе Великобритании не начало увеличиваться до середины июня. И до августа-сентября его объем проталкивания оставался на высоком уровне по сравнению с аналогичным периодом прошлого года. Тем не менее, люди в часовом поясе Великобритании работают дольше и больше с июня.

Анализ среднего еженедельного окна отправки сообщений и рабочей нагрузки (среднее количество сообщений) для разработчиков в часовом поясе Великобритании показывает, что в этом часовом поясе:

Пуш-окна в основном занимают от 3,9 часов в пятницу до 4,4 часов в среду.
Рабочая нагрузка в основном составляла от 13 коммитов в пятницу до 15 коммитов в среду.
В субботу было наибольшее количество коммитов, до 20.

Увеличение количества пушей по выходным может быть связано с тем, что меньшее количество разработчиков вносят код в выходные дни. Но это также может означать увеличение личной рабочей нагрузки, например, работы над проектами с открытым исходным кодом, хобби или учебных пособий. Поскольку разработчики заняты делами, связанными с работой в течение недели, разработчики используют выходные для работы над личными проектами. Стоит отметить, что аналогичные ситуации бывают и в часовых поясах, отличных от стандартного часового пояса Японии. Это будет объяснено позже при анализе этого часового пояса.

Пуш-окно EST и анализ рабочей нагрузки

Что касается восточного побережья США, то на протяжении большей части 2020 года у разработчиков были относительно короткие окна для пушей: в марте они выросли, а в августе выровнялись, что на две-три минуты больше, чем за тот же период прошлого года. Падение в ноябре произошло из-за праздника благодарения.

Из анализа данных застройщиков в этом часовом поясе видно, что:

Пуш-окна в будние дни варьируются от 4,4 часов в понедельник до 5,3 часов в среду.
Рабочая нагрузка варьируется от 12 коммитов в понедельник до 13 коммитов в среду.
Воскресные коммиты увеличились до самого высокого уровня — 16.
Загрузка разработчиков в воскресенье такая же, как и в понедельник, а то и выше.

Окно push-уведомлений в часовом поясе США по тихоокеанскому региону и анализ рабочей нагрузки

Из анализа видно, что длина push-окна изменилась по сравнению с аналогичным периодом прошлого года, увеличившись с середины марта, в целом достигнув 30-60 минут в неделю. Эта ситуация продолжалась в июне и начала стабилизироваться в начале июля. Причем на протяжении всей второй половины июля она увеличивалась на 5-7 минут по сравнению с аналогичным периодом прошлого года, а затем снова уменьшалась в августе. Кроме того, взлеты и падения в ноябре были вызваны праздником Благодарения.

Количество пушей от разработчиков в тихоокеанском часовом поясе в течение всего года было выше, чем в прошлом году. Начиная с мая активность увеличилась более чем на 50% по сравнению с прошлым годом во многих областях, а затем упала на 25% по сравнению с прошлым годом в сентябре. В этом обзоре из ситуации с отправкой кода видно, что в этом году в часовом поясе Тихого океана всегда была самая высокая рабочая нагрузка разработчиков по сравнению с другими часовыми поясами.

В этом часовом поясе:

Пуш-окна в будние дни варьируются от 4,5 часов в понедельник до 8,3 часов в среду.
Еженедельные рабочие нагрузки варьировались от 16 коммитов в понедельник до 17 коммитов в среду.
Коммиты были самыми высокими в воскресенье — 23.

Анализ также выявил интересную тенденцию: активность корпоративных разработчиков снижалась в выходные и праздничные дни. Но в то же время значительно возросла активность проектов с открытым исходным кодом, что свидетельствует о том, что люди обращались к открытому коду, когда откладывали свои рабочие задачи. С апреля создание проектов с открытым исходным кодом также увеличилось на 25% в годовом исчислении. Особенно сейчас, когда многие люди работают удаленно. Открытый исходный код дает нам возможность разрабатывать, создавать, учиться, сотрудничать и делиться с сообществом.

Push-окно часового пояса Японии и анализ рабочей нагрузки

Наконец, в отчете анализируется стандартный часовой пояс Японии. С середины ноября 2019 года ежедневное рабочее время японских разработчиков увеличилось (на 5-15 минут) по сравнению с аналогичным периодом прошлого года. Начиная с апреля мы наблюдаем, как окна push-уведомлений становятся длиннее, а разработчики начинают тратить на работу на 20-52 минуты больше в день. В июне эта цифра сократилась примерно на 15 минут в день больше, чем в то же время в прошлом году.

В этом часовом поясе:

Пуш-окна варьируются от 4,3 часов в пятницу до 4,8 часов во вторник.
Средняя ежедневная нагрузка на одного разработчика составляет 9 коммитов в неделю.
Воскресная рабочая нагрузка сократилась до 8 коммитов.

В отличие от аналогичных ограничений, введенных в США и Великобритании, меры, принятые японским правительством, носят необязательный характер и не влекут за собой никаких наказаний для физических и юридических лиц. Таким образом, влияние смены режима работы может быть незначительным.

Производительность имеет значение

COVID-19 и внезапный переход на удаленную работу оказали большое влияние. Однако разработчики делают больше работы, чем в это время в прошлом году. Мы рады, что производительность все еще растет в условиях неопределенности, но действительно ли она устойчива? Для некоторых людей работа на дому высвободила продуктивность, позволяя им работать на своих условиях, настраивая свою рабочую среду по своему усмотрению, с минимальным отвлечением. И больше времени на обеденные перерывы, физические упражнения и время с семьей. Это невозможно при работе в компании, возможно, потому, что рабочая среда открытой планировки слишком шумная, или офисная среда не может быть настроена индивидуально, или поездка на работу слишком длинная, чтобы быть достаточно гибким, чтобы планировать день.

Однако многих людей, которые только начинают работать удаленно, это может разочаровать. Для некоторых людей удаленная работа затруднила общение и общение. Многие люди также не имеют рабочего места дома, не имеют необходимого для работы оборудования и должны заботиться о своих детях самостоятельно или с кем-то еще. Граница между работой и жизнью станет размытой, а время, ранее потраченное на поездки на работу, станет рабочим временем, что приведет к увеличению продолжительности рабочего дня. Несмотря на это, многие до сих пор чувствуют, что времени не хватает и выполнить работу в срок сложно.

Вот несколько советов, как повысить эффективность работы и избежать выгорания:

Каждый день уделяйте несколько минут размышлениям о вещах, за которые вы благодарны. Некоторые разработчики говорят, что это положительно влияет на их менталитет.
Помимо управления своим временем, управляйте своей энергией. Найдите подходящие для вас режимы работы, которые могут поддерживать высокую эффективность работы, и постоянно оптимизируйте эти режимы. Если вы любите рано вставать, сначала сделайте важные дела. Если вы более продуктивны днем или вечером, вы можете координировать свои действия с другими коллегами.
В команде поддерживайте гибкий, устойчивый график работы и помните о выгорании членов команды. Это помогает сделать нашу команду и нас самих счастливее и продуктивнее.

Чтобы получить дополнительные советы по работе из дома, ознакомьтесь со следующими статьями:

Удаленная работа: как родители адаптируются к удаленной работе во время COVID-19
Удаленная работа: как сотрудничать удаленно
Подкаст: Родители за удалённую работу

Деятельность разработчиков

Активность разработчика (или поведение разработчика) — еще один аспект производительности. Измерение активности разработчика как части производительности — сложная задача, но при правильном подходе она также может быть полезной. Это может помочь разработчикам выявить передовые методы управления задачами, координации работы и решения проблем. Для руководителей команд это может устранить барьеры в работе и помочь командам лучше работать вместе и достигать лучших результатов.

Данные в этом разделе получены из годового анализа всей активности GitHub (публичных и частных, включая проекты с открытым исходным кодом). Сравниваются периоды времени с 1 октября 2019 г. по 30 сентября 2020 г. и с 1 октября 2018 г. по 30 сентября 2019 г. На приведенном ниже графике показано годовое изменение географического распределения пользователей, включенных в анализ.

Значительный рост активности разработчиков

В этом отчете анализируются запросы на вытягивание, push-уведомления, рассмотренные запросы на вытягивание и рассмотренные проблемы для каждой учетной записи. В целом, эти цифры не изменились или увеличились по сравнению с тем же периодом прошлого года.

Если не указано иное, данные на графиках еженедельно нормализуются для каждого разработчика. Провалы данных в конце 2019 года совпали с праздниками. В этом отчете анализируется объем пулл-реквестов и пушей на человека в день, и обнаруживается, что активность продолжает расти по сравнению с прошлым годом. Мы также проанализировали рассмотренные запросы на вытягивание и рассмотренные проблемы и пришли к аналогичному выводу: цифры были выше, чем в прошлом году, и в целом оставались неизменными в течение всего года.

Данные также показывают, что он был постоянным или даже увеличился во время вспышки COVID-19 и работы из дома. Стоит отметить, что хотя влияние различных факторов вызвало огромные изменения в том, как мы работаем, соответствующие данные не сильно изменились, что указывает на то, что гибкие инструменты, процессы и решения могут поддерживать производительность разработчиков и даже продолжать достигать новых высот в лицо серьезных перемен. Облачная разработка может предоставить разработчикам лучший опыт разработки и более стабильную и гибкую модель разработки для команд и организаций. Кроме того, в этом отчете также отмечается, что гибкость полезна и для разработчиков, позволяя разработчикам делать это, разделяя свою работу.

Сотрудничество является изюминкой развития

Некоторые команды работали удаленно, в том числе штатные команды и проектные группы с открытым исходным кодом, в то время как другим пришлось работать удаленно впервые. Чтобы изучить, как изменение рабочей среды может повлиять на критически важную совместную работу, в этом отчете анализируются данные о экспертных оценках в запросах на вытягивание.

Запросы на включение — это способ для разработчиков сообщить другим, какие изменения они внесли в репозиторий. Запрос на вытягивание может включать в себя некоторых заинтересованных разработчиков, которые просматривают изменения перед слиянием, которые могут просматривать изменения, обсуждать код и иногда фиксировать. Наконец, запрос на извлечение будет объединен с соответствующей веткой соответствующего репозитория. Чтобы оценить этот совместный процесс, в этом отчете измеряется время, необходимое для объединения запросов на вытягивание, и сравнивается с тем же периодом прошлого года.

В репозиториях с открытым исходным кодом время, необходимое для перехода от создания пулл-реквеста к слиянию, варьируется, причем большинство больших колебаний происходит в праздничные дни — вообще говоря, слияние пулл-реквестов в этом году занимает больше времени, чем в прошлом году, на 3,5 часа. опережая год, постепенно замедляется до 3 часов вперед по сравнению с предыдущим годом. Кроме того, начиная с середины февраля 2020 года скорость слияния пулл-реквестов стала выше, чем в предыдущем году, и она сохранилась, сократив общее время на 1–7 часов.

Анализ кода рабочей среды показал, что в конце 2019 года среднее время выполнения пулл-реквестов было больше, чем в предыдущем году, среднее время на складе команды было на 1,5 часа больше, чем в предыдущем году, а среднее время в корпоративной учетной записи было больше, чем в предыдущем году: 1,5–4,2 часа. По мере того, как члены команды берут больше времени на отпуск (т. е. отпуска), время, необходимое для слияния, увеличивается, а количество отзывов в пулл-реквестах уменьшается.

На начало 2020 года видно, что время слияния по-прежнему больше, чем в предыдущем году, но оно улучшилось: время применения группового хранилища увеличено на 1-2 часа, а время применения корпоративного облака склад удлиняется на 0,1-1 час. В марте время слияния запросов на включение резко сократилось, а затем увеличилось, и эта закономерность оставалась неизменной до конца года: время слияния запросов на слияние в репозиториях команд сократилось на 5 часов, а на 6 часов быстрее для Enterprise Cloud Warehouse.

существуетв недавних интервью, разработчики и руководители проектов делятся опытом своей команды с помощью запросов на вытягивание. Согласованная передовая практика заключается в том, чтобы количество исправлений в запросах на вытягивание было небольшим, потому что это упрощает проверку, повышает качество проверки и упрощает откат, если что-то пойдет не так. Кроме того, это усиливает положительную обратную связь, что способствует повышению мотивации каждого к созданию и повышению продуктивности команды.

Изменения в объеме создания задач

Кроме того, в отчете также анализируется количество задач, созданных на GitHub. До вспышки COVID-19 количество задач, создаваемых на GitHub в день, было меньше или равно аналогичному периоду в предыдущем году. Как показано стрелками, это начало меняться в середине марта и оставалось таким на протяжении всего анализа. Опять же, падение данных в конце 2020 года соответствует праздникам.

Примечание. GitHub объявил о бесплатных групповых учетных записях 14 апреля 2020 г., и в этом отчете также анализируются данные, чтобы выяснить, связано ли увеличение активности в бесплатных учетных записях с изменениями политики учетных записей или реальным ростом активности. Анализ показал, что половина увеличения данных об активности была связана с COVID-19, поскольку в течение года наблюдался заметный рост создания проблем для бесплатных учетных записей, и это значительно отличалось от активности для корпоративных учетных записей.

Дальнейший анализ выявил аналогичные сдвиги в темпах роста создания задач во всех репозиториях, при этом наибольший рост наблюдался в репозиториях, принадлежащих бесплатным учетным записям разработчиков и платным групповым учетным записям. На графике ниже показано изменение количества выпусков, созданных на складе, по сравнению с аналогичным периодом прошлого года. Можно отметить, что пики и провалы данных корпоративных облачных учетных записей в конце ноября были вызваны праздником Дня Благодарения в США.

Развитие не пострадало

Данные анализируются в связи с глобальными событиями и могут быть разделены на три отдельных этапа: с октября по декабрь 2019 г. (до COVID-19), с января по март 2020 г. (ранняя стадия вспышки COVID-19), с апреля 2020 г. по сентябрь 2020 г. ( большинство разработчиков начинают работать из дома). С этой точки зрения анализ показал, что данные о проблемах между корпоративными учетными записями и бесплатными учетными записями различаются, особенно после апреля 2020 года.

Обратите внимание на линию тренда, и на графике видно, что данные по Free Warehouse сильно изменились.

Если мы также разобьем push- и pull-запросы по этим диапазонам дат, мы увидим небольшое увеличение данных в течение года, но никаких заметных изменений в активности. Поскольку push- и pull-запросы являются основной частью деятельности по разработке, изменение рабочего места не слишком сильно на них повлияет.

Анализ показал, что даже при увеличении нагрузки на разработчиков за последний год фактический размер пуша (количество файлов, измененных в каждом коммите) как характеристика) остается примерно такой же. Вместо этого проблемы используются для отслеживания и планирования работы и более подвержены сбоям.

Корпоративный облачный репозиторий и проблемы

Данные по корпоративным облачным хранилищам показывают две основные закономерности: годовые показатели были относительно стабильными до апреля 2020 года, после чего общие показатели снизились. Видно, что в середине апреля и примерно в мае наблюдался всплеск активности по созданию задач, вероятно, из-за того, что разработчики перешли на работу из дома, поэтому усилия по разработке координировались через задачи. Тем не менее, в отчете не говорится о том, что темпы создания проблем возвращаются к уровню прошлого года. Это может быть связано с тем, что корпоративные команды больше привыкли следить за разработкой с помощью проблем.

Бесплатные репозитории и проблемы

Данные Free Warehouse также показывают две основные модели активности: до апреля 2020 года годовые показатели были относительно стабильными или немного ниже. Затем мы увидели огромный скачок в данных и, казалось, выровнялись в мае (21% в среднем с апреля по дату, 22% медиана). Среди бесплатных репозиториев анализ не выявил такого резкого падения количества проблем за выходные, вероятно, из-за деятельности, связанной с открытым исходным кодом, увлечениями и учебными пособиями.

Автоматизация способствует развитию

Важно доставлять код быстро и надежно с помощью автоматизированных средств. Возможность получить быструю обратную связь во время написания кода, чтобы подтвердить, что их код может быть развернут, очень важна для разработчиков, которые немедленно выполняют следующее требование, а не вручную развертывают свой код.

В этом отчете анализируется, как кодовые базы с открытым исходным кодом используют действия для автоматизации своих запросов на вытягивание. Сосредоточьтесь на запросах на вытягивание, потому что они являются ключевой точкой пересечения в процессе разработки. Внедрив автоматизацию на этом этапе, команда может уведомить других о необходимости проверки запроса на вытягивание и начать тестирование и сборку после завершения проверки.

Во всех репозиториях с открытым исходным кодом, когда они начали использовать действия, время объединения запросов на вытягивание сократилось на 18%, а количество объединенных запросов на вытягивание увеличилось на 34%. Команды, которые используют автоматизацию в своих рабочих процессах, могут ускорить доставку своего программного обеспечения, поскольку они могут быстрее объединять запросы на вытягивание, быстрее продолжать писать код, а затем быстрее объединять больше кода в свои проекты. Это благотворный круг, оптимизированные методы разработки программного обеспечения также предоставляют разработчикам лучший опыт, который может приносить постоянную пользу.

Автоматизация не только ускоряет доставку программного обеспечения. Есть также исследования, показывающие, что автоматизация также может уменьшить количество ошибок и улучшить качество отправляемого кода, что также дает разработчикам больше времени для разработки и инноваций.

Промышленный стандарт

Часто спрашивают, что является отраслевым стандартом для деятельности разработчиков. Команда GitHub рекомендует вам использовать эти тесты, чтобы проанализировать свои собственные методы программирования и подумать о том, что можно улучшить в зависимости от вашей ситуации.

В рабочих проектах и проектах, ориентированных на интересы, код разработки может несколько отличаться, поэтому для контроля различий здесь анализируются только данные из корпоративной среды. при этих обстоятельствах:

Разработчики обычно коммитят код четыре раза в день.
Обычно с момента создания запроса на включение до момента его слияния проходит 1,6 часа.
Цикл проверки кода обычно составляет 1 час.

В отчете временная шкала для запросов на вытягивание и обзоров также разделена для анализа. Как видите, первая проверка запроса на включение обычно занимает 54 минуты, а время от последней проверки до слияния составляет 12 минут. С момента создания запроса на включение до момента его слияния прошел 1 час 36 минут. Кроме того, в большинстве случаев только один человек просматривает запрос на вытягивание, поэтому между первой проверкой и последней проверкой не проходит время, но это может привести к задержкам, если происходят другие проверки.

Глядя в будущее

То, что анализируется в этом отчете, является естественным глобальным «экспериментом», который показывает, что удаленная работа намного успешнее, чем мы думали ранее. Отрасль здравоохранения, которая всего год назад объявила удаленную работу невозможной, теперь нашла безопасные и надежные способы предоставления услуг в соответствии с требованиями окружающей среды.

В этом отчете отмечается, что количество разработчиков GitHub росло по сравнению с прошлым годом, что соответствует типичному росту платформы, а также возросла активность отдельных разработчиков. Более того, очень приятно иметь такой рост данных в условиях постоянных изменений моделей работы, стратегий компании, экономической и рыночной среды. Это также показывает, что облачная разработка обеспечивает разработчикам, командам и организациям более стабильную и отказоустойчивую разработку. А анализ рабочего времени и нагрузки показывает, что разработчики также выигрывают от гибкости. Гибкость позволяет им более гибко организовать свою работу.

Повлияет ли это на модель централизованного офиса? Из выводов отчета в сочетании с исследованием команд, которые начали возвращаться к работе:

Команды могут обнаружить, что модель работы, которая лучше всего подходит для них, — это сочетание удаленной и локальной работы.
Даже вернувшись на традиционное рабочее место, мы обнаружили, что рабочие часы все еще длиннее. Особенно «ночная смена» встречается чаще.
Предоставляйте гибкие решения, чтобы разработчики могли создавать свои собственные решения для обеспечения устойчивости работы.
Сетевые условия и совместная работа настолько важны, что даже если произойдет разрушительное событие, оно не окажет чрезмерного воздействия.

Модель работы за год показывает нам, что люди делают больше работы, больше дел. Это может быть результатом повышения производительности за счет использования автоматизации, более эффективных методов разработки и более гибких офисных моделей, которые стирают границы между работой и жизнью.

Мы все более податливы, чем думаем.

Спасибо

Автор: Николь Форсгрен

Специалисты по данным: Грег Чеккарелли, Дерек Джедамски, Скот Келли, Клэр Салливан

Рецензенты: Дене Форд, Мартин Фаулер

Редакторы-копирайтеры: Лия Кларк, Шерил Купе, Стефани Уиллис

Дизайнеры: Шивон Дойл, Аджа Шамбли

Примечание. Эта статья основана наОтчет GitHub 2020Написано, строго не переведено. ты можешь пойти вПрограмма перевода самородковЧтобы загрузить китайский перевод этого отчета, перейдите по ссылкеOCTOVERSEЗагрузите оригинальную английскую версию.

Найдите общедоступный аккаунт WeChat «Technology Talk», подпишитесь на более интересный контент.