Сегодня разработчикам доступен фантастический ассортимент инструментов и технологий, которые они используют для создания цифрового мира. Однако огромное количество вариантов в цепочках инструментов DevOps и непрерывной интеграции/непрерывного развертывания (CI/CD) создает огромное количество сложностей, что приводит к многочисленным неэффективным результатам. О призванной решить эту проблему новой дисциплине DPE (инженерия продуктивности разработчика), в которой большую роль играют продвинутая аналитика и искусственный интеллект, порталу Datanami рассказал Ханс Доктер, генеральный директор Gradle, компании, стоящей за ведущим одноименным Open Source-инструментом.

По его словам, хотя появление методов DevOps и CI/CD во многом упростило жизнь разработчиков, оно также породило трудности, препятствующие продуктивной работе.

Начнем с того, что тестирование критически важно для обеспечения того, чтобы ПО не содержало ошибок и не представляло угрозы безопасности. Благодаря таким инструментам сборки, как Gradle, Apache Maven и Bazel, разработчикам больше не нужно вручную выполнять различные замысловатые шаги, необходимые для внедрения новой функции или исправления ошибки в производстве. Как утверждает Доктер, благодаря большому числу интеграций, поддерживаемых сообществом Open Source-разработчиков, такие инструменты могут устранить значительную часть этой тяжелой работы.

В некоторых крупных корпоративных или веб-приложениях может быть порядка 10 000 тестов, которые необходимо выполнить, прежде чем код будет запущен в производство. Это означает, что даже для самых незначительных изменений кода может потребоваться около суток для выполнения всех проверок. Умножьте это на тысячу или около того разработчиков, и вы быстро окажетесь в трясине разработки.

«Есть немало компаний, где время ожидания выполнения цепочки инструментов составляет несколько часов в день. Это слишком долго», — говорит Доктер.

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

«Для большинства инженеров в нашей отрасли очень трудно выяснить первопричину проблемы, — говорит он. — У них не хватает данных, чтобы понять, несут ли они ответственность за эту проблему. Или может быть в этом виноват коллега?».

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

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

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

Это основная предпосылка корпоративных продуктов Gradle, а также дисциплины DPE в целом. По мнению Доктера, DPE имеет потенциал для преобразования разработки ПО путем введения элементов строгости, инженерии и воспроизводимости на основе данных, как это уже сделали другие индустрии.

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

Доктер уверен, что большие данные и ИИ сыграют большую роль в будущем DPE. Его компания создала команду специалистов по науке о данных и выпустила свой первый продукт на основе ИИ. Predictive Test Selection использует МО для прогнозирования того, какие части кодовой базы чувствительны к изменениям, а какие тесты можно смело исключить из жизненного цикла DevOps.

«Теперь мы можем сказать вам: „О, вы изменили эту часть ПО. Но 9000 из 10 000 тестов вам не нужно запускать, потому что мы знаем из наших данных, что эти тесты совершенно нечувствительны к этим участкам кода. Только 1000 тестов чувствительны к этой области, поэтому давайте запустим только эту тысячу“», — поясняет Доктер.

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

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

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

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

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

«Как вы можете себе представить, это огромный шаг к зрелости индустрии ПО, — говорит Доктер. — Путь к успеху еще долог. Но если кто-то сможет сказать: „За последние четыре недели у нас стало на 7% меньше неработающих тестов“, то это укажет на явный прогресс».