Russian Association of Software Architects

В Архитектурных Этюдах новый кейс: https://t.me/archicases/9786/9787

Вот так Notebooklm сжал теорию первого дня корп курса по Event Storming, очень хорошо сжал, я бы сказал. Никакой лишней информации нет, так что можно выложить :)

SPDD (Structured Promt Driven Development) https://martinfowler.com/articles/structured-prompt-driven/ Пришла пора подвести итоги использования SPDD, как самостоятельного, так и в рамках консалтинга. Я не увидел в SPDD чего-то, что бы фундаментально меняло подход к разработке, в сущности – это инструмент для того, чтобы обуздать и дисциплинировать работу ненадежным, стохастическим генератором кода (хотя Мартин Фаулер иного мнения - «material change in how developers build software», можно так сказать, но даже сама статья не сказать, что этот тезис раскрывает). Инженерная работа, которую ранее разработчик мог выполнить во время написания кода, – проработка структуры сущностей, описание модели, фиксация атрибутов качества, определение инвариантов, теперь, как и завещали нам все инженерные школы (начиная с XP) выносится вперед, как проработка конкретной задачи перед началом работы над ней, иначе нейронка просто не реализует то, что нужно. Все дело в том, что разработчики (developers) к моменту начала разработки обладали большим количеством неявного знания отовсюду, - из доков, ранее написанного кода, жизненного опыта, кучи встреч и случайных обсуждений. Логично, что у нейронки этого нет и это надо: a) вынести из головы в промт б) структурировать должным образом Такой Structured Promt обычно содержит не мало подробностей (REASONS), чуть приземленнее: ▪️в какой слой вносить изменения ▪️конкретные изменения в API и какие API трогать нельзя ▪️какие инваринаты домена нельзя нарушать ▪️какие тесты обязательны ▪️какие граничные кейсы обязательно обработать ▪️какие архитектурные соглашения соблюдать ▪️что считается успешным результатом В целом, выгоды очевидны, их ощущаешь даже в одиночку: ▪️[Возможная] повторяемость, причем спустя долгое время (все же зависит и от модели и от температуры и от самого промта, тут не очевидно) ▪️Более точный результат, тут без комментариев – больше деталей – точнее результат ▪️Если есть ревью, людьми, то ревью проходит лучше – есть описание задачи и результат, своего рода сверка ▪️Быстрые драфты, особенно там где надо кучу кода изменить, – можно делать небольшие изменения в промте, которые распространяются сразу на много частей системы, объективно быстрее при накопленной строгой структуре ▪️Senior пишет правила, по которым составляется промт, всякие чеклисты, шаблоны и в целом ребята с меньшим опытом могут ими пользоваться Однако, у всего есть побочка: ▪️Не просто так разработчики решали задачи в процессе разработки, – постепенное продвижение в решении с каждым шагом открывало новые вопросы, которые в момент обсуждения голосом могли даже не возникнуть в голове, пресловутое «о, а тут что должно быть?». Соответственно, глобально меняется модель мышления – сначала решение, затем модель пишет код. Это теперь _требует_ использования структурированных методов решения инженерных задач, коих много, но которые часто игнорировались. Похоже, этим практикам и методам теперь дается вторая жизнь. ▪️Чтобы грамотно поставить задачу нейронке, нужно с ней общаться на понятном ей языке, а она понимает любой язык (и сила и слабость). То есть если ей не сказать – здесь лучше использовать Chain of Responsibility и Builder, то она с высокой вероятностью не будет их использовать. А это методы локализации изменений, а локализация изменений – прямой метод оптимизации потребления токенов и повышения вероятности успеха при внесении изменений. То есть нужен точный доменный и инженерный язык. ▪️Все это нужно описать словами. А это бывает нудно. Если человек привык писать код по 10 часов в день в течение 10 лет, то перейти к написанию спецификаций может оказаться сложным (но придется) В итоге SPDD снижает стоимость печатания кода 🙂 Но повышает важность постановки задачи, декомпозиции, верификации и архитектурной дисциплины. То есть это не про преимущество над классической разработкой в сложной инженерной работе, а скорее существенное преимущество в управляемом использовании LLM.

Я обещал написать, начал писать и уже получилось пять страниц, так что это будет уже статья, но кое что я все же напишу здесь. В прошлом году я выступил с темой «Экономические последствия архитектурных решений». В ней было о том, как архитектура влияет на экономику. После этого было несколько проектов, в которых мы реализовали оценку архитектурных решений в деньгах. Это оказалось проще, чем кажется на первый взгляд, но требует некоторых усилий в изменении процессов, модели принятия архитектурных решений и подходам к работе с инициативами. Однако встал очередной вопрос, который именно сейчас стал болезненным. Заключается он в том, что аналогия технического долга, и архитектурного в частности, завязана на деньги. Прошлым летом у меня было выступление на тему архитектурного долга, но суть в том, что мы всегда считали объем архитектурного долга в терминах технических метрик. И это большая проблема – архитектурные изменения дорогие, дорогие в терминах денег, а обоснование в большинстве источников через связанность, зависимости, избыточную сложность. Основная цель коммерческой организации – зарабатывать деньги, иначе с чего платить зарплату. И расходы тут играют не последнюю роль, как, конечно и доходы, но когда мы строим IT-стратегию или пытаемся обосновать выделение сервиса или что-то подобное, стоит это обычно сколько-то денег, например, месяц работы команды, а что это даст? В деньгах что даст. Вот мы решили апнуть версию базы, неделя команды, а выгода в деньгах какая? Может мы платим процентов по такому долгу 1000 рублей в год, тогда апгрейд версии базы не окупится условно никогда. Конечно, есть еще риски и иные факторы, но все же. Прямой способ, который описывается во всех источниках - учет времени на выплату процентов по долгу с переводом в деньги по ставке членов команды. Я подсознательно, и на своем опыте, и по опыту работы с различными компаниями, понимаю, что это красивая сказка, так не работает, – тут и отторжение и избыточная нагрузка… Но мы же инженеры и я решил проверить как обстоит дело и запустил опрос. Вот вижу, что кто-то все же честные трудозатраты считает, вопрос к корректности остается открытым, но все же это 20% от всех ответивших. По индустрии будет и того меньше, я думаю, что подводит нас к тому, что этот подход массово не рабочий. У меня есть несколько других подходов, которые я уже обкатал, которые по косвенным признакам позволяют все же перевести архитектурный долг в деньги, это и мой опыт и опыт коллег, с кем мы в тесном контакте. В скором времени выпущу статью и небольшое решение, которое позволит посчитать его. Важно - мой акцент на долге _над кодом_, потому что долг уровня кода сейчас отдается за минуты, почти бесплатно. Так как я с самыми мощными моделями и в доверенных источниках не нашел прагматичных методов, думаю, что это будет хорошее решение, а цель достаточно простая – объективно оценить, что отдавать, а что не надо, потому что в условиях бюджетных огранчений выбирать нужно очень аккуратно, ориентируясь на реальные финансовые показатели, а не только на технические параметры и метрики системы.

Ищу человека, который возьмёт на себя почтовую платформу на 100 млн ящиков Рынок почты в РФ переформатируется на глазах Старая модель «жить на чужой бесплатной почте» закончилась На этом фоне нужна экспертиза на почтовый сервис национального масштаба, до 100 000 000 ящиков, полностью в российском контуре Ищу не «инженера Postfix», а технического лидера направления того, кто возьмёт архитектуру/стратегию и результат на себя + соберёт команду под себя Тебе сюда, если ты: • строил или эксплуатировал почту/мессенджинг на десятках млн пользователей (Яндекс / VK / Mail.ru / крупный телеком / хостинг / RuPost); • держишь весь стек: распределённое хранилище и очереди, доставляемость на уровне IP-пулов, антиспам/антифрод; • понимаешь комплаенс на масштабе — 152-ФЗ, ОРИ, СОРМ (на 100 млн это фундамент, а не опция); • умеешь вести команду и отвечать за направление, а не только за конфиги. Формат обсуждаем — лид/Head, фуллтайм или партнёрство в проекте. Условия под уровень. Особенно ценно услышать тех, кто уже ловил грабли hyperscale-почты, которых нет в документации 👉 Отклик боту @kovalski_hairing_bot: пришли PDF (CV/опыт) и в подписи пару строк о себе. Одна заявка с человека, анализ будет в ручном режиме без ИИ =)

Мы продолжаем прием тем для выступления на archdays.ru Этот год богат на темы, подавайте, встретимся, обсудим :)

Structured-Prompt-Driven Development (SPDD) LLM programming assistants have demonstrated considerable value, but mostly with individual developers. The internal IT organization in Thoughtworks has been using them for their teams and have developed a method and workflow called Structured Prompt-Driven Development (SPDD). Wei Zhang and Jessie Jie Xia describe a simple example of this workflow with details in github. This workflow treats the prompts as a first-class artifact, kept with the code in version control, and used to align development with business needs. They have found that developers need three key skills to be effective: alignment, abstraction-first, and iterative review. more… via Martin Fowler

401 meetup – call for papers Друзья, пишу поделиться отличной новостью! Анонсирую оффлайн-митап про Identity & Access Management (IAM) в Москве 27 мая. Концепция: свободный вендор-независимый митап для сообщества. Подробности и начало регистрации для участников будут объявлены позднее, а пока приглашаю спикеров заявиться с докладами. Очень жду и приветствую доклады про аутентификацию, управление доступом и смежные области. Это будет классная возможность выступить на релевантную аудиторию. Тайминг 35-40 минут. Запись постараюсь организовать, чтобы материалы были доступны. Принимаем любые идеи, крутые технические или архитектурные доклады всегда в цене. А если вам нужно вдохновение, вот темы, о которых особенно хочется послушать: - Аутентификация и авторизация: MFA, passwordless, адаптивная risk-based аутентификация, Just-in-Time Access, политики и модели контроля доступа - Протоколы и стандарты: интересные, новаторские практики использования OAuth 2.0, OIDC, SAML, применение новых RFC и спецификаций - Безопасность identity: Identity Threat Detection and Response (ITDR), уязвимости, атаки на аутентификацию, контроль доступа и меры защиты от них - Практика и highload: опыт использования “нестандартного” Open Source (Ory, Casdoor, ZITADEL, etc.), адаптация IAM под высокие нагрузки и специфичные НФТ, разработка собственных IAM-решений - Новые вызовы: аутентификация и контроль доступа для AI-агентов и MCP - Enterprise-задачи: B2B IAM, федерации, мультитенантность - Customer IAM (CIAM): UX и безопасность, управление аккаунтами и согласиями, social login - Архитектура: аутентификация и контроль доступа в распределенных системах, service-to-service взаимодействия, SPIFFE - Интеграции: комплексные решения из нескольких компонентов: IdM, IAM, SIEM, API Gateway, etc. ⛔️ Для подачи заявки на доклад заполняйте форму. Прием заявок открыт до 1 мая (но времени не так много, не затягивайте). Со всеми заполнившими форму свяжемся. По вопросам можно писать Андрею Кузнецову. Сомневаетесь, подходит ли ваша тема? Оставляйте заявку – обсудим и подумаем вместе. Мы открыты к специалистам с различным опытом и профилем. Если у вас есть идея доклада, но вы никогда не выступали и переживаете, мы поддержим и поможем подготовиться <3 Напоследок TLDR: 📆 27 мая оффлайн в Москве, площадку согласился предоставить Яндекс 📩 Заявки на доклады присылайте в форму до 1 мая Stay tuned! #announce #iam_general

Новый кейс в Архитектурных Этюдах! «Расхождение между учетной системой и реальностью на складе» Как построить архитектуру информационной системы управления складом, при которой физическое состояние склада и его цифровое отображение остаются синхронизированными в реальном времени несмотря на то, что операции с материалами выполняют десятки людей, не заинтересованных в корректном вводе данных? https://t.me/archicases/9360/9362

Хм. Раньше настройки опроса в Телеграм по-умолчанию были такими: • Можно выбрать только один вариант ответа Теперь по-умолчанию через десктопное приложение осталось как и было раньше (можно выбрать только один вариант ответа), а в мобильной версии по-умолчанию теперь: • Можно выбрать несколько вариантов • Перемешивать варианты ответа при каждом отображении (новая настройка) Вот я и создал опрос, через мобильное приложение, мда 🙂 Вайбкодить начали, что ли 🙂

Новый кейс в архитектурных этюдах «Бонусы в архитектуре процессинга» https://t.me/archicases/8989/8990