Мы продолжаем прием тем для выступления на archdays.ru

Этот год богат на темы, подавайте, встретимся, обсудим :)

Ищу человека, который возьмёт на себя почтовую платформу на 100 млн ящиков

Рынок почты в РФ переформатируется на глазах
Старая модель «жить на чужой бесплатной почте» закончилась

На этом фоне нужна экспертиза на почтовый сервис национального масштаба, до 100 000 000 ящиков, полностью в российском контуре

Ищу не «инженера Postfix», а технического лидера направления того, кто возьмёт архитектуру/стратегию и результат на себя + соберёт команду под себя

Тебе сюда, если ты:
• строил или эксплуатировал почту/мессенджинг на десятках млн пользователей (Яндекс / VK / Mail.ru / крупный телеком / хостинг / RuPost);
• держишь весь стек: распределённое хранилище и очереди, доставляемость на уровне IP-пулов, антиспам/антифрод;
• понимаешь комплаенс на масштабе — 152-ФЗ, ОРИ, СОРМ (на 100 млн это фундамент, а не опция);
• умеешь вести команду и отвечать за направление, а не только за конфиги.

Формат обсуждаем — лид/Head, фуллтайм или партнёрство в проекте. Условия под уровень.

Особенно ценно услышать тех, кто уже ловил грабли hyperscale-почты, которых нет в документации

👉 Отклик боту @kovalski_hairing_bot: пришли PDF (CV/опыт) и в подписи пару строк о себе. Одна заявка с человека, анализ будет в ручном режиме без ИИ =)

Я обещал написать, начал писать и уже получилось пять страниц, так что это будет уже статья, но кое что я все же напишу здесь.

В прошлом году я выступил с темой «Экономические последствия архитектурных решений». В ней было о том, как архитектура влияет на экономику. После этого было несколько проектов, в которых мы реализовали оценку архитектурных решений в деньгах. Это оказалось проще, чем кажется на первый взгляд, но требует некоторых усилий в изменении процессов, модели принятия архитектурных решений и подходам к работе с инициативами. Однако встал очередной вопрос, который именно сейчас стал болезненным.

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

Прямой способ, который описывается во всех источниках - учет времени на выплату процентов по долгу с переводом в деньги по ставке членов команды. Я подсознательно, и на своем опыте, и по опыту работы с различными компаниями, понимаю, что это красивая сказка, так не работает, – тут и отторжение и избыточная нагрузка… Но мы же инженеры и я решил проверить как обстоит дело и запустил опрос. Вот вижу, что кто-то все же честные трудозатраты считает, вопрос к корректности остается открытым, но все же это 20% от всех ответивших. По индустрии будет и того меньше, я думаю, что подводит нас к тому, что этот подход массово не рабочий.

У меня есть несколько других подходов, которые я уже обкатал, которые по косвенным признакам позволяют все же перевести архитектурный долг в деньги, это и мой опыт и опыт коллег, с кем мы в тесном контакте. В скором времени выпущу статью и небольшое решение, которое позволит посчитать его. Важно - мой акцент на долге _над кодом_, потому что долг уровня кода сейчас отдается за минуты, почти бесплатно.

Так как я с самыми мощными моделями и в доверенных источниках не нашел прагматичных методов, думаю, что это будет хорошее решение, а цель достаточно простая – объективно оценить, что отдавать, а что не надо, потому что в условиях бюджетных огранчений выбирать нужно очень аккуратно, ориентируясь на реальные финансовые показатели, а не только на технические параметры и метрики системы.

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.

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

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

Domain-Driven Design matters more when AI writes your code

via Learn Building Modern Go applications

Поговорим о знании

Существует модель описания знания, включающая в себя три основных компонента:
- декларативное знание (что?)
- процедурное знание (как?)
- условное знание (когда и почему?)

Декларативное знание - это факты и утверждения, процедурное - правила действий.

Декларативное - предпосылка для процедурного. При этом в зависимости от обретаемого знания конкретные типы могут быть разного объема, где-то больше декларативного (теоретическая наука), где-то процедурного (езда на велосипеде).

При этом знание неотделимо от контекста и деятельности, в которой оно применяется. Подумайте о кешировании и про:
- разработку самого компонента кэша (разработчик)
- выбор класса и конкретной реализации (архитектор)
- настройка и мониторинг (SRE)
Таким образом, часть знания не существует в голове отдельно от практики, в которой она проявляется.

Помимо этого, в знании есть условные понятия, качественно меняющие понимание всей области. Вспомним снова про кеширование, с точки зрения архитектуры примером будет переход от «настроить идеально инструмент кеширования» к «пойти на компромисс между целостностью и скоростью».

Исходя из вышесказанного, декларативное знание предшествует процедурному, однако затем они развиваются в процессе обучения, но не обязательно синхронно.

Согласно модели Дрейфуса (на является универсальной, но применяется в образовании), на ранней стадии доминирует декларативное знание в виде явных, контекстно-независимых фактов, на поздних - все более интуитивным. Это, в частности объясняет, почему нельзя научиться проектированию архитектуры за короткое время, - принятие решений почти всегда контекстно-зависимое.

Универсальная модель обучения, таким образом:
- декларативные знания - обучение, чтение, наблюдение
- процедурные - повторяемая практика
- условный - накопление опыта в разных ситуациях

Важно отметить, что механизмы получения знания - не взаимозаменяемы.

Если вы идете на конференцию, например, ArchDays, - вы получаете декларативное знание, отберите для себя выступления, которые могут быть вам полезны, заранее подумайте, как сможете применить и после выступления спрашивайте спикеров именно о том, как применить, какие действия выполнять, обменяйтесь контактами, спрашивайте по мере продвижения, либо исследуйте более глубоко тему самостоятельно. Так вы получите максимальный эффект.

В организационном контексте подумайте следующем:
- достаточно ли у сотрудников декларативного знания, чтобы качественно выполнять процедуры (процессы)
- достаточно ли у сотрудников декларативного знания, чтобы реализовать в коде требуемые процедуры (фичи)
- существуют ли процедуры, развивающие то, что декларируется (мы инновационны.. но есть ли процедуры это развивающие, обучающие?)
- мы - гибкие, но заложены ли циклы обратной связи с последующими изменениями на основе этих циклов?
- ….

Для архитектора:
- декларативное - курсы, книги, доклады, документация
- процедурное - реальное проектирование систем
- условное - разбор компромиссов, работа с разными контекстами

NFR – это требование к чему именно?

Наверняка у всех вас в том или ином виде описаны атрибуты качества, такие как безопасность, производительность, масштабируемость. На первый взгляд все в порядке: они указаны и даже заданы количественно или качественно. Однако при детальном рассмотрении часто выясняется, что совершенно непонятно, к какому объекту относится требование.

Требование производительности – к чему конкретно? К продукту? К отдельному модулю? К сервису? К данным? К конкретному пользовательскому сценарию?

К каким проблемам это может привести?
▪️Компания берет на себя обязательства, которые невозможно проверить и защитить перед клиентом или регулятором: не зафиксировано, к какому именно объекту относятся эти обязательства
▪️Архитектурный артефакт невозможно однозначно спроектировать и протестировать, если NFR сформулированы без привязки к нему
▪️Требования нельзя проверить на полноту и согласованность между командами, поскольку отсутствует воспроизводимая практика определения объектов и границ NFR

Что разберем на вебинаре?
Одна из обязательных частей сценария атрибуты качества – объект, к которому относится требование.

На вебинаре обсудим два вопроса:
▪️Какими бывают объекты NFR?
▪️Как определить границы этих объектов?

Вебинар проведет Сергей Баранов.

🗓 8 сентября, 17:00 МСК
🔗 Подключение: https://scrumtrek.ktalk.ru/sccu2uneqagt

Регистрация не требуется – добавляйте событие в календарь, чтобы не забыть 🙂

Запись вебинара «Определение объектов и границ объектов NFR»

Youtube: https://www.youtube.com/watch?v=7sLMNBNCMi8
VK: https://vkvideo.ru/video-184472537_456239215

Новый кейс в «Архитектурных этюдах»

Как решаете задачи валидации, когда смешиваются в одной задаче и размытые формулировки и алгоритмически проверяемые (обязательно) факты?

https://t.me/archicases/10055/10056