Engineering Notes
02.12
Управление архитектурой в командах Я считаю, что грамотное управление архитектурой в командах не менее важно, чем написание надежного кода, хороший контроль качества или выстроенный процесс code-review.
В разных компаниях этот процесс называется по-разному: ADR, TDR, TAR и т.д. При этом суть у него одна - сделать так, чтобы разработчик перед тем как начать писать код, подумал о том, как этот код будет развиваться через месяц, полгода, год и далее.
Для этого обычно пишутся архитектурные документы, которые описывают суть изменений, содержат в себе различные схемы описания архитектуры, скоринговые таблицы для сравнения решений и другие артефакты.
Кто-то скажет, что это бюрократия 🙃 и будет прав, но только от части.
На самом деле, этот процесс решает часть важных задач:
- Погружение всей команды, а так же внешних стейкхолдеров (например, лидов из смежных команд) в единый информационный контекст. Если у вас вовлеченные команды, то они будут рады тому, что вы делитесь с ними своими планами.
- Получение обратной связи от коллег, которая часто может привести к более оптимальному решению. Часто коллеги имеют совсем иной взгляд на вещи, нежели мы сами.
- Согласование архитектуры по части ИБ. Чтобы потом к вам не пришли с вопросом о том, с кем вы вообще согласовывали публикацию сервиса во внешнем контуре и зачем это нужно 😄
- Формирование общего виденья в части целевой архитектуры проекта и компании в целом.
- Погружение инженерной команды в бизнес-контекст. Чтобы понимали не только то, какой код мы пишем, но и зачем мы его пишем.
В своих командах я уже дважды внедрял описание архитектурных решений и оба раза ничуть не пожалел.
Давайте подведем итоги. Вам скорее всего нужен такой процесс, если:
- Вы работаете в корпорации с большим и развесистым IT ландшафтом, в котором есть множество сервисов и интеграций
- Вы хотите погружать всю команду в общий контекст, а не только в конкретные задачи
- Вам нужно согласовывать свои решения с инфраструктурой, ИБ и другими техническими стейкхолдерами
- Вы не боитесь тратить несколько часов в неделю на проектирование сервисов и систем
Бонус-трек: шаблон архитектурного решения для High Level дизайна системы или сервиса. Адаптируйте под свои нужды и внедряйте :)
еще контент в этом сообществе
еще контент в этом соообществе
Engineering Notes
02.12
войдите, чтобы увидеть
и подписаться на интересных профи