Диалог с агентом как разбор классической архитектурной дилеммы У нас ScrumTrek практически все разрабатывается агентами. Бывало всякое. Поделюсь историей, которая произошла буквально сегодня. Банальная фича - отображать нумерацию элементов или нет, если отсутствует заголовок первого уровня, а второго - на месте. Детали не важны - показывать числа или нет в зависимости от условия. Мои первые размышления: ну это же логично, нет текста - нет номера. Ставлю задачу. А он мне – бро, а давай мож чекбокс сделаем, вдруг кому-то надо. Ну ты, думаю, умеешь смуту навести. Ладно, может и правда кому-то надо. А он не унимается – таких 70 блоков по всем страницам и 60 подпадают под твои критерии, у них убираем (снимаем чекбокс)? Я уже напрягся, – ты вроде не живой, чтобы живого Заказчика доводить вопросами, взял и сделал как сказали (sarcasm!). Но ведь правда – есть разные продукты, у них свои владельцы, есть разные ЦА под разные продукты, у них свой опыт, свои вкусы. Вопсчем, я породил техдолг 🙂 Cказал «добавляем чекбокс, везде оставляем как есть сейчас». А мораль этой истории лежит в нескольких плоскостях сразу: 1. Очень мелкое изменение может повлиять на непропорционально большое число людей (контекстов использования – это, например, – продукты, владельцы, сегменты пользователей, публичные материалы, экспортируемые документы, скриншоты, инструкции) 2. Очень мелкое изменение может иметь лавинообразный эффект на атрибуты качества, в неявных местах (объемы данных, скорость обработки, …). В ATAM такие параметры или архитектурные решения называются sensitivity points. А теперь, наверное, самое важное. Как завещал Кент Бек, вдохновленный выступлением Энрико Занинотто на конференции XP 2002, изменения бывают обратимыми и не обратимыми: ▪️Обратимые – это изменения стилей, локальная верстка, скрытые за фича-флагами эксперименты. Здесь агенты дают колоссальное преимущество в скорости проверки гипотез. ▪️Необратимые – изменение финансовых данных, утечки персональных данных, слом публичных API или падение репутации, то есть изменения, которые уже вышли во внешний мир. Такие решения нужно оценивать заранее настолько тщательно, насколько это практически возможно (need to be evaluated up front to the degree possible). Порожденный мной в истории выше техдолг с точки зрения кода отдается за 10 минут. Но только в случае, если изменение было обратимым, потому что в противном случае техдолг отдать получится, но репутацию реверснуть нельзя, придется нарабатывать заново. Но и это еще не все. Архитекторы работают во многом с будущим. И вот такие мелкие изменения запросто могут без должного анализа возыметь отложенный негативный эффект на атрибуты качества - заложенная уязвимость, рост объемов данных, поедающих бюджет на хранение и производительность, аналитические запросы, кладущие раз в месяц прод базу на лопатки. Что делать? До принятия решения о реализации: • Классификация решений по обратимости. Именно так обычно никто не классифицирует (или я не видел), обычно это продуктовый и технический анализ влияния (impact analysis) и последствий, этого обычно хватает • Конечно, ADR, куда без него • Сценарии атрибутов качества и анализ точек чувствительности (sensitivity points) Структурные методы: • Ограниченные контексты и явно закрепленное владение за ними (больная тема вообще всех) • Контракты интеграции • Архитектурные фитнес-функции, термин не сказать что сильно прижился, если проще – автоматизированные проверки архитектурных инвариантов в CI/CD Поставка и эксплуатация: • Progressive Delivery (сюда входят и фиче-флаги и канареечные релизы и dark launch). По своей сути – это попытка перевести изменения из необратимых в обратимые • Наблюдаемость и опережающие индикаторы атрибутов качества (одна из причин, зачем нужны формальные описания сценариев атрибутов качества) • Реестр техдолга с бюджетом погашения (иначе он будет просто пополняемым списком и не более) Полезное из этого канала в тему поста: ▪️Архитектура и методология ▪️Про DDD и понимание предметной области ▪️Экономические последствия архитектурных решений (youtube) + презентация