Автор: Фернандо Тейшера (Fernando Teixeira)
Оригинал статьи
Перевод: Ольга Алифанова

Что такое простота разработки?

Простота разработки, также известная как опыт разработчика или DX (developer experience) – тема, быстро набирающая популярность в области ИТ. Однако появилась она не вчера. Первые упоминания о ней относятся к ранним 2010-м, и в последнее время в сообществах разработчиков ей уделяется все больше внимания.

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

Когда мы говорим о «разработчиках», это включает любого вовлеченного в процесс разработки инженера, включая инженеров по обеспечению качества (QA) и тестировщиков, работающих над качеством ПО, а также любую иную техническую роль в тех же процессах.

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

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

Примеры простоты разработки

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

Автоматизированные тесты могут верифицировать правильность внесенных изменений

Разработчики могут легко прогонять различные уровни существующих автоматизированных тестов (юнит, интеграционные, E2E, и т. д.) для валидации функциональности и надежности внесенных изменений. Когда открывается пулл-реквест, автоматизированные тесты, настроенные в CI/CD, автоматически запускаются и валидируют правильность поведения приложения, что позволяет убедиться, что слияние и выкатка изменений безопасны. Тесты выполняются быстро, и у разработчиков короткая петля обратной связи.

Простая, безопасная и быстрая выкатка новых версий

Доказано, что практики непрерывной поставки напрямую связаны с улучшением опыта разработчиков. Исследования команды изучения и оценки DevOps (DORA) показали, что единообразная выкатка повышает мотивацию, улучшает качество кода, снижает выгорание и стресс, а также повышает удовлетворенность работой.

Короткое время ожидания разработчиков и отсутствие помех

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

Ассертивный мониторинг приложения

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

Простой откат и восстановление

Существует автоматизированный откат – разработчики могут легко откатить изменения на проде, чтобы исправить ошибку или устранить проблему.

Легко находимая документация и руководства для начинающих

Разработчики могут легко найти информацию, как настроить и запустить проект, в едином месте – например, ответы на вопросы «Каковы требования к технологиям?» и «Каков процесс развертки у этого приложения?»

Как связаны DX и качество ПО?

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

Но задумывались ли вы, как создаются баги и низкокачественное ПО? Можно перечислить ряд причин, включая:

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

Теперь спрошу вас, что у всего этого общего? Ответ таков: все это связано с опытом разработчика. Эти причины могут напрямую повлиять на то, как команда разрабатывает и поставляет ПО.

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

Как только вы это осознаете, то сможете поразмыслить над более толковыми способами предотвращения дефектов и улучшения качества ПО, помогающими команде улучшить DX. Роль QA постоянно развивается, и это, вероятно, важная новая область изучения для QA-инженеров.

Как приступить к улучшению DX в команде?

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

Первый шаг – оценить, где сейчас находится ваша команда. Считает ли она, что опыт у разработчиков позитивный? Чувствуют ли разработчики, что им постоянно ставят палки в колеса, испытывают ли недовольство существующими обстоятельствами? Что в основном влияет на DX вашей команды прямо сейчас?

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

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

Опыт разработчика и опыт инженеров по качеству: две стороны одной медали?

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

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

Тут все так же, как и с качеством ПО, которое несколько лет назад рассматривали, как головную боль исключительно тестировщиков, а позднее мы (тестировщики) попытались поднять этот вопрос снова, обсуждая культуру качества всей команды, которая делит за него ответственность. Если мы начнем определять опыт инженеров по качеству как нечто, относящееся только к тестировщикам, то позднее мы столкнемся с той же самой проблемой и увидим, что такие вещи, как DX, полезны для всей команды сразу.

Заключение

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

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

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

Обсудить в форуме