Волшебная кнопка

Прочитал отличную статью про тестирование, которую написал Александр Раковский, и она заставила меня подумать, что я хочу увидеть в любом проекте сразу, как говорится, с “порога”. Представьте, вы приходите в ~~новый~~ проект, делаете git clone и…

За всё время повидал разные репозитории, стили, подходы, рылся и с удовольствием продолжаю рыться в open-source, открывая что-то новое. Но знаете, что всегда напрягает при первом рассмотрении? Когда для запуска проекта и начала разработки недостаточно просто открыть IDE и нажать “волшебную кнопку”.

Подобные вещи нужно делать сразу, со старта проекта, и с каждым днём двигаться к максимальному упрощению этого процесса. Реализация “волшебной кнопки” может быть разной. Реальная кнопка или run-конфигурация в IDE, shell-скрипт, инструкция с описанием простых шагов, команда в Gradle, эмулятор, тест и т.д.

Почему это важно?

Быстрый онбординг. Сотрудник не тратит время на настройку окружения, с этим он разберётся чуть позже. Главная задача на старте — как можно быстрей войти в предметную область проекта и познакомиться с его кодовой базой.
Культура автоматизации. Разработчик становится на шаг ближе к операционной команде; начинает задумываться о том, как и где его код будет работать, как его будут эксплуатировать. Больше никаких отговорок в стиле: “Не знаю, у меня всё работает”.

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

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

На 2-м курсе проходил практику в ВЦ РЖД. Руководитель для прикола дал задание настроить FTP-сервер. Ну, как настроить… Взять из стоящей в углу пыльной коробки комплектующие, собрать из них сервак, установить на него Linux, скомпилировать и настроить FTP. С заданием я справился, но суть вы поняли. Спустя годы я попал на проект, для работы в котором нужно было запустить 5 экземпляров IDE, настроить и связать между собой 5 экземпляров Tomcat, установить и настроить базу данных и т.д. и т.п. И таким в команде занимался каждый. Следующие пару дней я потратил на автоматизацию запуска окружения и приложения в Docker. Время старта с нуля сократилось до минуты. После этого разработчики реже прерывались на кофе, зато их глаза стали не такие красные.

С чего можно начать?

Создайте в корне репозитория readme.md. Добавьте в него описание последовательности шагов, необходимых для сборки и запуска проекта.
Автоматизируйте описанные шаги. Можно не всё сразу, но шаг за шагом старайтесь сокращать количество ручных действий.
Вовремя актуализируйте эти артефакты. Чтобы всё было в актуальном состоянии, переиспользуйте эти практики в своём CI/CD.

Возвращаясь к теме тестирования… Я заметил, что в тех репозиториях, где нет банальной автоматизации, нет и тестов. Как правило, в таких командах отсутствует понимание значимости тестирования, а общий уровень инженерной культуры на достаточно низком уровне. Совпадение?

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

Понравилась статья?