Technical Design Review (TDR)

Зачем нужно кодревью — понятно. У каждой компании есть инструмент для кодревью. У многих команд есть договоренности и практики по кодревью. Например, «смотреть PR до стендапа», «критикуешь — предлагай» и тд.

Но у кодревью есть один большой минус: код уже написан. Когда появляются критичные комменты по архитектуре и нужно всё переписывать — очень демотивирует и может возникнуть конфликт.

Эту проблему решает TDR — Technical Design Review.
Это как кодревью, но про архитектуру и заранее: инженер описывает в Confluence предлагаемое решение и собирает обратную связь с команды и внешних ребят.

Как и в кодревью, есть плюсы, минусы и подводные камни.

Плюсы:

1️⃣ Более проработанное решение будет быстрее разработано и с меньшими проблемами.
Серьёзная проработка архитектуры до старта разработки даёт возможность полноценно попроектировать и учесть обратную связь.

2️⃣ Обмен знаниями и гарантия документирования.
Есть возможность научиться проектировать архитектуру у более опытных ребят. Проектировать может один, а разрабатывать — другой. Полноценная дока появляется еще до старта разработки.

3️⃣ Осведомленность команды и соседей.
При разработке будет меньше вопросов. Не будет проблем с интеграцией и вопросов «а что это вы тут делаете?». Не возникнет блокирующих рисков.

Минусы:

1️⃣ Увеличивает Time2market
Это компенсируется временем, сэкономленным на поддержке и рефакторингах. TDR = контроль за техдолгом.

Но есть подводные камни. TDR может «застрять на ревью» как задача на кодревью.
Причины могут быть разные, но результат — задержка реализации.

Способы решения этой проблемы — аналогичные для долгих кодревью:
— Договориться о сроках с ревьюерами.
— Определить в команде приоритет. В идеале, ревью кода и ревью TDR — приоритетнее, чем написание нового кода по своим задачам.
«Сел утром за работу — посмотри пулл реквесты и TDR».
— Заранее предупреждать о предстоящем ревью в следующем спринте. Просить запланировать ревью.
— Иметь четкую систему оценок и критичности комментов: что обязательно к исправлению, а что опционально.
— Иметь гайдлайны о том, что должно быть в TDR: компонентные и sequence-диаграммы, оценки объема данных и нагрузки, оценки рисков, план миграции, план отката. Это снимет часть вопросов, возникающих на большинстве TDR.


2️⃣ Иногда TDR делают там, где он не нужен, замедляя разработку. А иногда не делают там, где нужен, порождают риски.
Проблема в отсутствии договоренностей, какие изменения должны проходить через TDR.

Есть общие рекомендации по уровню влияния. Например, если есть выход за рамки команды — желателен TDR.
Впрочем, никто не настучит по голове, если TDR не будет. В итоге каждая команда сама решает, что выносить, а что — нет.
Поэтому нужно выписать четкие критерии для проведения TDR.
Например:
— Создание нового микросервиса
— Выбор базы данных
— Интеграция с внешней системой


Итог

Мы провели около 10 TDR за полгода.

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

Но в целом польза от TDR точно перевешивает.
Советую ли я читателю TDR?
— Однозначно, стоит попробовать!

Если у вас есть похожий опыт — делитесь в комментариях.