ADR
При разработки программных продуктов команды вынуждены принимать решения. Некоторые решения являются ключевыми, их будет сложно быстро изменить в будущем. Например, что использовать как базу данных — MongoDB или PostgreSQL?В хороших командах, перед принятием решения, мы обсуждаем разные варианты. В итоге принимаем лучшее решение на основе доступной информации. Его еще называют informed decision.
Например, мы собрались, оценили
DynamoDB, MongoDB и PostgreSQL и решили что будем использовать PostgreSQL. Это сработало хорошо, стартап стал успешным 🚀. Через 3 года все участники той дискуссии уже работают в других компаниях тимлидами, а над стартапом работают новые разработчики. Через день они клянут 🤬 своих предшественников — почему тут PostgreSQL, ведь намного лучше подошла бы Neo4j у нас тут граф графом погоняет.Проблема не в технологии, проблема в том, что новая команда не знает контекста, в котором было принято предыдущее решение. Решить эту проблему можно введя практику
Architecture decision record (ADR). ADR это документ, в котором вы описываете ключевые решения для проекта, почему вы их приняли, что вы учли и какие последствия вы предвидели.Например, можно договориться, что в каждом проекте в корне будет папка
/adr и в ней будут документы, составленные по такому простому шаблону. Каждый документ проходит merge request процесс, где другие участники команды могут оставить свои комментарии. В итоге контекст принятия решения сохраняется навсегда и лежит рядом с сервисом — очень удобно ✅.⬛️ Еще раз — не нужно бояться принимать решения. В сложных вопросах правильного решения нет, но есть лучшее, согласно имеющейся информации.
ADR позволят сохранять контекст вместе с проектом, это очень помогает в долгосрочной поддержке продукта.А вы как, используете
ADR? Пишите в комментариях.#хардскиллы