Авиатор спонсировал этот пост.
Внедрение сложных помощников по кодированию ИИ в корне изменило способ работы разработчиков. То, что когда-то потребовалось часы концентрированной печати и отладки, теперь может быть достигнуто за считанные минуты с помощью хорошо продуманных подсказок и итеративного сотрудничества с инструментами ИИ.
Сегодняшний процесс разработки часто выглядит так:
Этот рабочий процесс мало сходства с традиционным процессом кодирования, где разработчики писали каждую строку вручную. Навыки, которые имеют значение, изменились от скорости ввода и синтаксического запоминания к составу проблемы, оценки решений и эффективного сотрудничества с инструментами искусственного интеллекта.
Одержимость технологий измерением производительности
Старая поговорка говорит, что вы не можете улучшить то, что не можете измерить. Но технологическая индустрия вырвала это из контекста, став одержим измерением «все, что мы можем», несмотря на то, что более двух десятилетий назад Мартин Фаулер, архитектор современного разработки программного обеспечения, писал, что производительность разработчика не может быть измерена.
Метрики производительности разработчика полезны для понимания узких мест в инженерных процессах, но они не являются целью.
Метрики все еще важны. DevOps Research and Assessment (DORA)-это стандартный набор метрик для измерения и сравнения производительности DevOps, разработанной командой DORA, инициативой Google Cloud, которая способствует хорошей практике DevOps.
Но метрики — это только компас для определения того, что не так в инженерном процессе, а не решение. И определенно не способ измерить индивидуальную производительность.
Необходимость измерить все, по -настоящему, вспыхнуло во время Covid, когда мы начали работать удаленно, и не было хорошего способа понять, как была проделана работа. Часть этого также связана с неуверенностью руководства в понимании того, что происходит в разработке программного обеспечения.
Однако при обследовании о полезности показателей производительности разработчиков большинство лидеров признают, что метрики, которые они отслеживают, не являются репрезентативными для производительности разработчиков и, как правило, объединяют производительность с опытом. И теперь, когда большая часть кода написана ИИ, измерение производительности одинаково имеет еще меньше смысла. Если ИИ улучшает усилия по программированию на 30%, означает ли это, что мы получаем на 30% больше производительности? »
Что убивает производительность?
Разработчики также довольно четко понимают, что сделает их более продуктивными. Отчет Atlassian Other of Developer Experience показал, что 69% разработчиков теряют восемь часов в неделю — 20% своего времени — неэффективности. Ключевыми точками трения являются технический долг (59%), отсутствие документации (41%), процессы сборки (27%), отсутствие времени для глубокой работы (27%) и отсутствие четкого направления (25%).
Независимо от того, называете ли вы это Devex или Platform Engineering, отсутствие трения равняется счастливым разработчикам, что равняется продуктивным разработчикам. В том же опросе 63% разработчиков заявили, что опыт разработчиков важен для удовлетворенности их работой.
Антиметрический подход: автоматизированные рабочие процессы
Вот почему я верю в подход антиметрического подхода к производительности разработчиков и сосредоточив внимание на устранении необходимых, но мирских задач, с которыми сталкиваются разработчики каждый день.
Вместо того, чтобы создавать блестящие панели мониторинга, инженерные лидеры должны сосредоточиться на опыте разработчиков и автоматических рабочих процессах по всему жизненному циклу разработки программного обеспечения: разработка, обзоры кода, сборки, тесты и развертывания.
Это означает сосредоточение внимания на решении реальных проблем разработчиков, а не просто указывать на проблемы.
Отслеживание инженерных показателей производительности по -прежнему важно. Тем не менее, метрики — это лишь компас для определения того, что не так, а не решение. Реальное влияние на опыт разработчиков происходит от балансировки трех ключевых рычагов: людей, практики и инструментов.
Эти инструменты должны полагаться на пять основных методов доставки:
Разработка на основе сундука, согласно этому определению, представляет собой «модель ветвления источника, где разработчики сотрудничают в коде в одной ветви под названием« Trunk » *, сопротивляйтесь любому давлению, чтобы создать другие долгоживущие филиалы развития, используя документированные методы. промышленность ».
Непрерывная доставка — это практика, когда изменения кода автоматически создаются, протестированы и подготовлены к выпуску до производства. Этот подход позволяет командам развертывать изменения кода чаще и надежно и имеет решающее значение для высокопроизводительных инженерных организаций. Автоматизируя конвейер доставки, команды могут поддерживать постоянный поток обновлений, обеспечивая при этом качество и стабильность. Как сказал Брайан Финстер, страстный защитник непрерывной доставки: непрерывная доставка — это всегда быть доставкой, возможность развернуть последние изменения в производстве в любой момент. Автоматизируя конвейер доставки, команды могут поддерживать постоянный поток обновлений, обеспечивая при этом качество и стабильность. Обратите внимание, что непрерывная доставка отличается от непрерывного развертывания, и более важно иметь непрерывную доставку, даже если развертывание запускается вручную или при заданном каденции.
Настройка Monorepo помогает установить последовательные стандарты в разных проектах путем централизации конфигураций сборки, правил внедрения и рабочих процессов разработки. Эта стандартизация снижает когнитивные накладные расходы для разработчиков, перемещающихся между проектами и обеспечивает единый контроль качества. Наличие всего кода в одном месте также упрощает управление зависимостями и перекрестные изменения.
Небольшие, целенаправленные обзоры кода помогают поддерживать высокое качество кода и производительность разработчиков. Разбивая изменения на более мелкие, усваиваемые предметы, рецензенты могут предоставить более подробную обратную связь и улавливать потенциальные проблемы раньше. Этот подход также уменьшает когнитивную нагрузку на рецензентов и ускоряет процесс обзора, что приводит к более быстрым циклам итерации.
Универсальное владение активами разработчиков способствует четко определенной общей ответственности и обмену знаниями по всей команде. Когда все чувствуют себя владением кодовой базой, это поощряет сотрудничество, уменьшает знания и гарантирует, что любой член команды может внести свой вклад в любую часть проекта.
В то время как фреймворки и панели мониторинга метрик по -прежнему играют роль в инженерных организациях, если мы действительно заботимся о производительности разработчиков, нам нужно прекратить одержимость информационными панелями и начать сосредоточиться на том, что на самом деле помогает командам выполнять свою лучшую работу.
Как команда бывших гуглеров, мы начали искать инструменты для замены Google EngProd, команды, ориентированной на создание инструментов и инфраструктуры для оптимизации инженерного процесса. Поскольку Google строит все на месте, не все легко воспроизводимо. Это привело нас к созданию Aviator — восстановление инженерной производительности Google (Engprod) в современном инженерном стеке для решения проблем сотрудничества на каждом этапе процесса разработки, от обзоров кода до сборки, тестирования, слияния и развертывания.
Aviator-это разработчик с низким содержанием конфигурации, работающий с AI, который автоматизирует владение, обзоры кода, слияния и развертывание. Он создает организационный график знаний для упрощения назначения билетов, резюме проекта и поддержки внутренней разработчиков. Узнайте больше последних из Aviator Trending Stories YouTube.com/thenewstack Tech Moving быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Ankit Jain является соучредителем и генеральным директором Dev-Productivity Startup Technologies, а также возглавляет сеть бывших выпускников Google. Ранее он руководил инженерными командами в Sunshine, Homejoy и Shippo, а также был инженером в Google и Adobe. Узнайте больше от Ankit Jain
