Как устроены команды и процессы разработки

Что проверяют

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

Как отвечать

Опишите структуру и поток задачи.

Состав. Кросс-функциональная команда: разработчики, тестировщик, аналитик, продукт, иногда выделенный инженер по инфраструктуре. Либо команда только из разработчиков, а тестирование и аналитика распределены. Оба варианта рабочие, важно, чтобы ответственность была явной.

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

Что специфично для команд на Go и что стоит назвать:

• обязательные проверки в конвейере: сборка, go vet, набор линтеров через golangci-lint, тесты с детектором гонок. Последнее важно: без него конкурентные ошибки просто не находятся;
• форматирование не обсуждается, его делает штатный инструмент. Это снимает целый класс споров на ревью;
• структура проекта и границы пакетов: договорённость, где лежат домен, транспорт и хранилище, потому что стандарт языка её не навязывает;
• работа с зависимостями: минимализм по духу языка, обновление и проверка уязвимостей.

Релизы. Частота, флаги функциональности, как выкатывается и как откатывается.

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

Общение. Ежедневная синхронизация, ретроспективы, где фиксируются архитектурные решения.

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

Где спотыкаются

Называют методологию по имени вместо описания реального потока.

Не знают, как в их команде делается выкладка и откат.

Не гоняют тесты с детектором гонок.

Описывают только свою часть работы.