Все начало года я занята подготовкой и защитами ADR. И да, это одна из нескольких причин, почему я сейчас пропала из блога. Понять, простить)

Но, как оказалось, в моём окружении далеко не все сталкиваются с ADR и даже не все знают, что это такое.

Разберемся? Основы:

ADR или Architecture Decision Record, или запись архитектурного решения (хотя в практике я никогда не слышала русского варианта) это документ, где фиксируют важные для разработки архитектурные решения: их описание, варианты реализации, риски и причины, почему выбрали именно этот вариант.

Да, очень даже протокольная бумага для мира ИТ. По крайней мере, на первый взгляд.

Там где такой практики нет, я встречала следующее:

😱 В решении не учитывались какие-то важные технические тонкости и толстости, которые уже есть в продукте или прямо сейчас появляются в соседних командах.

😱 Решения приходилось откатывать спустя пару релизов. Поспешили с внедрением.

😱 Компетенции самых “прошаренных” специалистов редко передавались остальным. С ADR картина маслом, когда спецы вскакивают с словами "Да вы мне там все сломаете, мы же уже внедрили *много полезной информации*

😱 Частые недоумения: “Да почему вообще так сделали и кто?”. особенно у новичков. Хотя кого я обманываю?

Сейчас, после внедрения ADR и защиты, эти “болезни” почти вылечились. Дополнительно команде в целом стало интереснее: на исследование выделяется время и чувствуешь свою ответственность, потому что нужно своё решение защитить.
Кстати... Получается не всегда. У меня в этом году удалось из 3 попыток только 2, причем один со второй попытки, с замечаниями.

В целом шаблоны +- стандартные. Хотя у каждой команды могут отличаться. Вот, например, буквально на днях на курсе по архитектуре от GetAnalyst делились таким забавным шаблоном. Ну и в целом больше об ADR здесь

Как у меня проходит работа над ADR, почему это отнимает столько сил, а также может ли аналитик сам проработать крутое архитектурное решение - расскажу в следующий раз.