Showcase-проекты

Вместо pet-проектов, которые у большинства из нас застывают в состоянии как на картинке¹, я практикую создание showcase-проектов. Этот подход хорошо зарекомендовал себя и прижился (как мне кажется) в моей команде.

Что такое showcase-проекты?

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

Для чего они нужны?

В первую очередь, для расширения собственного кругозора и понимания, как на самом деле работает “эта штука”.

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

Как создавать showcase-проекты?

Выберите тему для исследования. Полезнее всего, если она будет связана с вашими актуальными задачами. Тогда разбираться будет интереснее, и у вас будет мотивация. Например, актуальными для меня в недавнее время были такие:

• ассиметричное шифрование на открытом ключе;
• поддержка распределенного трейсинга;
• работа с Temporal²;
• и адаптация AsyncAPI³.

Создайте небольшой самодостаточный репозиторий. Опишите в нём минимальную инфраструктуру, необходимую для развёртывания локально. Это может быть скрипт запуска виртуальной машины и набор плейбуков ansible, файлик docker-compose или спека куба. Ваша цель на этом этапе — сделать так, чтобы окружение было воспроизводимым, и его легко было развернуть, выполнив одну комаду.

Напишите минимальный объём кода, позволяющий убедиться, что “шестеренки закрутились”. Получите минимальный выхлоп. Вас никто не заставляет обрабатывать грамотно все возможные ошибки, следовать указаниям линтеров. Если удобнее выкинуть на любой ошибке панику — спокойно выкидывайте. Для понимания и демонстрации коллегам нужно показать “мясо”.

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

Потушите виртуалку и остановите код. Убедитесь, что всё можно завести с чистого листа. Этим примером, скорее всего, будут пользоваться ваши коллеги, и разворачивать они будут его из чистой рабочей копии без артефактов.

Что должны в себя включать и что не должны?

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

У вас это может быть репозиторий, состоящий из одного файла main.[ваш_язык], наглядно демонстрирующим способы применения изучаемого инструмента.

Повторюсь, добивайтесь воспроизводимости. Примеры должны заводиться из чистой рабочей копии репозитория.

Как мы адаптировали этот подход в команде?

Каких-то особых сложностей в этом процессе я не испытал.

У нас выделена отдельная группа репозиториев, в которой лежат наши showcase-проекты. Имена говорят сами за себя, поэтому промахнуться сложно.

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

Итого

• Чего-то не знаем, имеем недостаточный опыт применения или “заржавело” — создаём showcase.
• Изучаем, делимся полученным опытом.
• Фиксируем в системе контроля версий для самих себя и новых коллег.

Попробуйте.