LinkedIn открыла исходный код своей платформы Productivity and Happiness Framework для разработчиков

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

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

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

Измерение производительности

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

Во-первых, продуктивность разработчика - это смесь материальных и нематериальных условий. Что мы знаем о том, насколько хорошо был определен проект, были ли личные конфликты внутри команды? И, возможно, самое важное - счастливы ли эти разработчики на самом деле?

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

Связь с продуктивностью и счастьем разработчиков

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

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

LinkedIn - это продукт ее разработчиков, и компании необходимо, чтобы они были продуктивны и счастливы. Поэтому ей необходимо понять, что эти два ключевых требования значат для нее как организации. Основываясь на собственном опыте и опыте других организаций, включая Mozilla, компания разрабатывает и внедряет систему Developer Productivity and Happiness (DPH) Framework, которая обеспечивает руководство по оценке собственных процессов разработки.

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

Изменение методов разработки требует изменения управления

Одной из важных составляющих LinkedIn DPH Framework является понимание того, как эволюционировала разработка программного обеспечения. Мы всегда понимали, что время сборки должно учитываться в любом показателе производительности, но переход от водопада к agile и CI/CD (непрерывная интеграция и непрерывная доставка) изменил эту ситуацию. Теперь каждое движение кода может привести к сборке, причем автоматизированные тесты являются частью этого процесса. Мы также должны учитывать обзоры кода, время, затрачиваемое на тестирование и обработку запросов на внесение изменений до их принятия.

Многие из метрик, которые использует LinkedIn, получены из самих инструментов, будь то производительность локального набора инструментов на компьютере разработчика или облачной CI/CD-платформы. Цель состоит в том, чтобы найти блокировки и "дроссели", мешающие созданию кода, и убедиться, что пользователи получают наилучший опыт.

Эта новая модель требует новых методов работы. Разработчики больше не могут предоставлять огромные блоки кода, так как они будут ждать завершения рецензирования. А рецензенты не могут допустить возникновения отставания. Используя метрики DPH, мы можем определить, что облегчает работу обеих сторон. Это может привести к более частым, но меньшим по объему заявкам, которые легче понять, легче протестировать и быстрее утвердить, а значит, код будет легче поддерживать и понимать.

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

От цифр к результатам

Очень хорошо, что у вас есть система для определения производительности разработчиков и определения используемых метрик, но как превратить эти данные в действия? Одним из ключевых элементов является наличие какой-либо приборной панели или портала для отображения данных и применения статистической значимости. LinkedIn создала так называемый Developer Insights Hub на основе DPH, что позволяет легко увидеть ключевые данные, такие как среднее время ожидания завершения сборки, а также любые отклонения.

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

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

Следующие шаги: распространение на другие организации

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

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

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