ADR — записи архитектурных решений
Рекомендация
Рекомендация
Заголовок раздела «Рекомендация»Решение с долгосрочными последствиями фиксируется ADR-записью (Architecture Decision Record) — короткой страницей в базе знаний: контекст, рассмотренные варианты, принятое решение, последствия. Триггеры, когда ADR нужен:
- выбор способа интеграции (HTTP-сервис vs план обмена vs файлы vs шина);
- расширение vs доработка конфигурации vs отдельная база;
- схема хранения (свой регистр vs допреквизиты БСП vs справочник);
- отказ от типового механизма в пользу самописного (или наоборот);
- всё, о чём через год спросят «а почему тут так странно сделано?».
ADR нумеруются, не редактируются задним числом: устаревшее решение получает статус «заменено ADR-NNN», а не тихую переписку истории.
Код показывает, как сделано, но не почему. Через год контекст исчезает: человек ушёл, переписка утонула, и команда либо карго-культит странное решение («так исторически сложилось»), либо ломает его, не зная, от какой граблины оно защищало. ADR стоит 20 минут при принятии решения и экономит дни на каждом «давайте перепишем» — потому что спор начинается не с нуля, а с записанных вариантов и причин отказа.
Когда не применять
Заголовок раздела «Когда не применять»- Типовая задача по существующим стандартам — не ADR: решение уже продиктовано стандартом, достаточно ссылки на него.
- Локальные решения без долгосрочных последствий (имя реквизита, структура формы) — обычное описание изменения в MR.