> For the complete documentation index, see [llms.txt](https://akrisanov.gitbook.io/team-playbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://akrisanov.gitbook.io/team-playbook/engineering-practices/developer-velocity.md).

# Скорость разработки

Developer velocity – это скорость и эффективность, с которой команда разработки может создавать, изменять и развертывать качественный код.

Velocity – это не всегда про измеримые метрики и включает в себя внедрение инженерных практик, автоматизацию рутины, коммуникацию в командах и непрерывное обучение.

Скорость разработки напрямую влияет на производственный цикл разработки программного обеспечения – Software Development Lifecycle (SDLC).

### Чеклист

* Технический стек представляет собой ограниченное кол-во core-языков и технологий → нет [проблемы «зоопарка» технологий](https://matt-rickard.com/minimal-viable-frameworks).
* В разработке используется ограниченное кол-во сторонних сервисов, что позволяет митигировать риски, связанные с вендорами; предпочтение отдается решениям с открытым исходным кодом (self-hosted) и сервисам с хорошей документаций, поддержкой и возможностью тестирования.
* Реализовано быстрое развертывание локальных окружений для разработчиков через Docker Compose и др. инструменты.
* Разработчики могут собирать и тестировать сборки (или большую часть сервисов) локально.
* Интеграционные тесты могут быть запущены локально.
* Разработчики пишут тесты, которые [фокусируются на качестве кода и его поддержке](https://matt-rickard.com/your-integration-tests-are-too-long), а не на проценте его покрытия.
* Инженеры (включая QA) могут легко развернуть необходимую инфраструктуру для разработки и тестирования изменений.
* Быстрый цикл разработки
  * Фронтенд: hot-reload
  * Бэкенд: инкрементальные быстрый билды
  * Для маленьких команд: оптимизированный BuildKit Dockerfile
  * Для больших команд: настроеная система воспроизводимых (reproducible) сборок
* Отсутствие сабмодулей при работе с Git – [баланс монорепозиториев и микросервисов](https://matt-rickard.com/monorepos).
* Воспроизводимая сборка пакетов и/или Docker-образов.
* Стандартизированные подходы к именованию веток, сообщению коммитов и merge-реквестам, которые позволяют поддерживать либо линейную историю, либо держать контекст в feature-ветках и оперативно откатывать изменения.
* Стандартизированный и быстрый процесс ревью кода.
* Автоматизация посредством CI/CD пайплайнов, возможность смотреть логи задач.
* Возможность развертывания окружений для merge-реквестов.
* main (master) ветка всегда готова к релизу.
* Автоматизированные сборки и релизы.
* Адекватное время развертывания изменений и сервисов на продакшене: для небольших сервисов – до 5 минут, для небольших монолитов – до 15 минут; для средних и больших проектов и команд – до часа.
* Доступные всей команде инструменты мониторинга и уведомлений.
* Инфраструктура как код (IaC), которая позволяет быстро развертывать новые окружения и версионировать изменения.