Что вы хотите увидеть в любом проекте сразу, как говорится, с “порога”. Представьте, вы приходите в новый проект, делаете git clone и…
За всё время повидал разные репозитории, стили, подходы, рылся и с удовольствием продолжаю рыться в open-source, открывая что-то новое. Но знаете, что всегда напрягает при первом рассмотрении? Когда для запуска проекта и начала разработки недостаточно просто открыть IDE и нажать “волшебную кнопку”.
Подобные вещи нужно делать сразу, со старта проекта, и с каждым днём двигаться к максимальному упрощению этого процесса. Реализация “волшебной кнопки” может быть разной. Реальная кнопка или run-конфигурация в IDE, shell-скрипт, инструкция с описанием простых шагов, команда в Gradle, эмулятор, тест и т.д.
Почему это важно?
- Быстрый онбординг. Сотрудник не тратит время на настройку окружения, с этим он разберётся чуть позже. Главная задача на старте — как можно быстрей войти в предметную область проекта и познакомиться с его кодовой базой.
- Культура автоматизации. Разработчик становится на шаг ближе к операционной команде; начинает задумываться о том, как и где его код будет работать, как его будут эксплуатировать. Больше никаких отговорок в стиле: “Не знаю, у меня всё работает”.
Автоматизируя локальную сборку и запуск, начинается перестройка сознания в нужном направлении, начинают стираться границы между разработкой, тестированием, DevOps, SRE. Перестаёт существовать “мы” и “они”, все разговаривают на одном языке, решают общие задачи и действуют как единый организм.
Казалось бы, всё очевидно, зачем про это говорить. К сожалению, отсутствие таких банальных вещей встречается достаточно часто. При этом мне ни разу не доводилось услышать стоящих аргументов в защиту такого попустительства. Можно придумать кучу оправданий, почему нет тестов, но нет никаких оправданий, почему для сборки и запуска проекта нужно потратить весь день.
На 2-м курсе проходил производственную практику. Руководитель для прикола дал задание настроить FTP-сервер. Ну, как настроить… Взять из стоящей в углу пыльной коробки комплектующие, собрать из них сервак, установить на него Linux, скомпилировать и настроить FTP. С заданием я справился, но суть вы поняли. Спустя годы я попал на проект, для работы в котором нужно было запустить 5 экземпляров IDE, настроить и связать между собой 5 экземпляров Tomcat, установить и настроить базу данных и т.д. и т.п. И таким в команде занимался каждый. Следующие пару дней я потратил на автоматизацию запуска окружения и приложения в Docker. Время старта с нуля сократилось до минуты. После этого разработчики реже прерывались на кофе, зато их глаза стали не такие красные.
С чего можно начать?
- Создайте в корне репозитория readme.md. Добавьте в него описание последовательности шагов, необходимых для сборки и запуска проекта.
- Автоматизируйте описанные шаги. Можно не всё сразу, но шаг за шагом старайтесь сокращать количество ручных действий.
- Вовремя актуализируйте эти артефакты. Чтобы всё было в актуальном состоянии, переиспользуйте эти практики в своём CI/CD.
Возвращаясь к теме тестирования… Я заметил, что в тех репозиториях, где нет банальной автоматизации, нет и тестов. Как правило, в таких командах отсутствует понимание значимости тестирования, а общий уровень инженерной культуры на достаточно низком уровне. Совпадение? :)
***
P.s. Напоминаю, что у меня есть Telegram-канал "Архитектоника в ИТ", где я публикую материал на похожие темы примерно раз в неделю. Подписчики меня мотивируют, но ещё больше мотивируют живые дискуссии, ведь именно в них рождается истина. Поэтому подписывайтесь на канал или на мой блог здесь. Будем обмениваться опытом и мнениями. ;-)