За всё хорошее, против всего плохого

В статье Software engineering practices представлен обширный набор советов. Разберём их подробнее.

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

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

Отработанный механизм миграций
Проблема миграций может оказаться бомбой замедленного действия. Памятуя кривой релиз, когда сидели всем селом и разгребали проблемы миграций. А потом ещё прилетело от какого-нибудь начальника за даунтайм. Разработчик будет идти на хитрости (читай — вставлять костыли), только бы не делать калечащих миграций.
Вообще тема миграций без даунтайма очень непростая. Про это у нас был отдельный пост.

Шаблонный проект
Иметь шаблонный проект особенно важно при использовании микросервисной архитектуры. Мы с самого начала такой подготовили и активно поддерживаем, дополняя актуальными для большинства сервисов моментами. Это нужно, чтобы избежать зоопарка таких похожих, но таких разных сервисов. Чтобы, зайдя в любой проект, разработчик чувствовал себя как дома :)

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

Автоматизированная среда предварительного просмотра
Тут автор говорит о том, что необходимо иметь некую среду, где можно посмотреть и запустить изменения конкретного merge request. Нам кажется это избыточно и не очень нужно. В целом, для обкатки изменений есть dev-контур, где разработчик что угодно может потыкать. А если хочется на стадии ревью запустить код, то в ридми всегда актуальная информация, как локально поднять сервис.

#edu