Comments 5
Каталог ADR образует иерархию, поэтому без связей одних решений с другими быстро образуется несвязная каша. Местоположение членов одной команды и её размер большого значения не имеют, а вот их управленческая автономность - еще как. По ADR делаются фитнесс функции, которые помогают идентифицировать техдолг.
GPT писал? Проставлены иконки, жирный шрифт, поверхностно и частично бессмысленно убедительно. Фтопку.
Спасибо, что уделили время на прочтение поста и составление такого подробного фидбэка.
Возможно, я действительно переборщил с иконками, раз они увели внимание от первого абзаца с мотивацией и целью.
Вижу, что вы хорошо разбираетесь в теме. Возможно, вы могли бы написать подробный гайд с примером того, как нужно писать без применения форматирования, чтобы текст читался легко и удобно. С удовольствием перениму ваш опыт, репостну и добавлю в библиотеку контента по ADR
я себе представляю это как некий архив с описанием мотивации(поставновка задачи), вводная в контекст, рамки отведенные вопросу в коде(тоесть его иерархическая категория), обзор/возможно первоначальные вопросы, и решение, а потом его фиксация в условиях проекта наверно - ну звучит как архив )
10 лет назад, когда автор начинал делать первые шаги в профессии, техдиры обычно держали набор документации трех-четырех слоев детализации - IT strategy, standards, guidelines, best practices. Обычный для того времени governance выглядел действително как архив. Сейчас ADR трансформировал нижние слои в граф - темплейт ADR имеет ссылки, о чем в статье ни слова. Такой переход не только упростил работу с решениями (decisions), но и представил их не как очередную бюрократию, а стал инструментом управления архитектурой информационных систем компании в среднесрочной перспективе, встроенный прямо в SDLC. Некоторые называют такую практику decision driven development.
ADR: фиксируем архитектурные решения