Позовите Олега | Архитектура и разработка

Всем привет. 🤩 Кто давно меня читает или знает лично, тот в курсе: я много лет занимаюсь архитектурой, проектированием надёжных систем и обучением разработчиков. За это время я видел много кейсов, где архитектура постепенно деградирует: появляются костыли, лишние зависимости, странные очереди, неочевидные ретраи, проблемы с консистентностью, мониторинг «для галочки» и решения, которые уже никто не может нормально объяснить. Сейчас навык проектирования становится ещё важнее. Код всё чаще можно делегировать AI-агенту. Архитектурное решение — нет. Агент может быстро написать сервис, какую-то логику, тесты или миграции. Вот только он не решит (на самом деле решит, но ты не сможешь узнать правильно или нет) за тебя, какие требования важны, где границы системы, какую нагрузку нужно выдержать, где нужен синхронный контур, где асинхронный, как хранить данные, как обрабатывать отказы и какие trade-offs придётся защищать. Поэтому я запускаю интенсив по System Design и архитектуре.

Лично я устал от скучных лекций с кучей теории. Собрал в интесиве максимум практики: как разбирать архитектурные задачи, считать нагрузку, выбирать компоненты, проектировать API, работать с базами, очередями, кешами, мониторингом, масштабированием и отказами.

 Подробности про интенсив расскажу отдельно, а начать предлагаю с открытого разбора архитектурной задачи. Будем проектировать notification service. На разборе посмотрим: — какие требования нужно собрать перед проектированием; — как оценить нагрузку; — какие компоненты нужны в такой системе; — где нужны очереди, базы, кеши и воркеры; — как масштабировать сервис; — какие trade-offs нужно учитывать; — какие ошибки чаще всего делают в такой архитектуре; — как защитить итоговое решение. Перед разбором я подготовил небольшой бонус — короткую диагностику архитектурных навыков. За несколько вопросов можно понять, где сейчас просадка: требования, нагрузка, базы, очереди, масштабирование, observability или аргументация решений. Пройти диагностику и зарегистрироваться на открытый разбор можно в боте: @mifle_courses_bot

Про отдых. Всем привет. Вы умете отдыхать? Расслабление, восстановление и вот это вот всё? Отключаться от внешних раздражителей? Мыслей о работе, деньгах, счетах? Если да, то я вам искренне завидую. Честно говоря, даже на отдыхе, мне сложно отвязаться от всех мыслей, задач, груза ответственности. Хотя для меня, есть один вид отдыха, который действительно освобождает голову и даёт возможность переключиться и отвлечься. Рыбалка. Особенно активная. Я не из тех, кто будет до глубокой ночи кормить комаров, лишь бы вытащить тровейную рыбу. Или кто будет на дрейфующей льдине гоняться за ещё одной поклёвкой. Да и что делать с пойманой рыбой — не знаю. В основном, отпускаю обратно. Увлекает сам процесс и удовольствие от него. Результат не предсказуем и не гарантирован, если зацикливаться на нём, можно быстро выгореть и бросить такой вид хобби. Интересно, что это кореллирует почти со всеми занятиями в жизни. Если не ловить наслаждение от процесса, то можно быстро бросить любое дело, потому что результат не гарантирован и не обязателен. А когда достигнут, становится не таким интересным, каким было до этого. В эти выходные совершили поездку семьёй в Карелию. 4 часа в одну сторону, 4 часа обратно. Лес, река, природа, семья, друзья. Для меня это переключение было важным и нужным. Следующие несколько месяцев лета будут очень насыщенными работой и проектами. ⭐️ стартует очередной поток System Design для студентов университета Иннополис. В этот раз лекции полностью на английском. ⭐️ лекции по архитектуре под высокие нагрузкт в Otus, где я уже третий год веду занятия про индексы, базы, распределённые системы и архитектуры. ⭐️ новые интересные треки на работе ⭐️ буду запускать свой образовательный проект, о котором расскажу уже завтра. 🤗 А пока немного фотокарточек из Карелии. Делитесь фотками ваших хобби и отдыхов в треде ⤵️

После поста про хайдоад сразу 5 человек отписалось 😀 Наверное подумали, что это реклама и я сказачно на этом разбогател. Или посто конференции не любят. Но коварный план у меня был. Коварный план разыграть билет онлайн доступа на Saint HighLoad++ 2026. 💵 Тем более нужно для этого всего ничего: ✅ Быть подписаным на мой канал ✅ Сделать репост в публичный чат \ свой канал \ к себе в историю какой-то из постов из моего канала ✅ Прислать скриншот репоста в комментарий к этому посту А уже через неделю подведу итог и передам проходку! Чтобы вам было легче выбрать пост, вот мои любимые: Что не так с CAP-теоремой? Я тимлид, но почему мне так грустно? Разбор задачи system design - передача местоположения курьеров. Серия постов про шаблоны низшего порялдка. Про порядок полей в составном индексе.

Всем привет! В этом году я не выступал и не посещал никакие конференции. И, честно говоря, уже порядком по ним соскучился. Совсем скоро, 22 и 23 июня в Питере пройдёт Saint HighLoad++ 2026. Я там буду и планирую походить на доклады. Вообще, в этом году ну очень много докладов про ИИ, внедрении ИИ и проечее ИИ. Я насчитал 20 из 50 докладов на HL. Т.е. больше 1/3, что дофига для конференции про высокие нагрузки. А про ахитектуру всего 1 доклад, 1 воркшоп, и игра по System Design (что, кстати, очень интересно, жаль я не смог поучасвовать в отборе). Вот мой топ потенциально инетересных докладов, которые хочу послушать: Я люблю копаться в кишках баз данных, по этому воркшоп "Допиливаем свой форк Постгреса свистелками" хочу посетить и попробовать собрать что там получится. Мне часто приходится дебажить агентов, когда сам пишу с их помощь, по этому воркшоп "Смотри, как думает агент: Observability AI-агентов с Langfuse" выглядит очень привлекательным. Схожу на доклад Ивана Поддубного "Уровни зрелости внедрения AI в процессы разработки", поскольку часто сам вижу внедрения ИИ в команды и, чаще всего, очень топорное. Послушаю "Как жить без строгой консистентности и не терять деньги", надеюсь это не доклад-пересказ документации. Автор доклада из финтеха, интересно как финтех уживается с evantual consistency. А если и вы будете на конфе, то подходте поболтать и обсудить доклады и воркшопы.🫰

Всем привет! В этом году я не выступал и не посещал никакие конференции. И, честно говоря, уже порядком по ним соскучился. Совсем скоро, 22 и 23 июня в Питере пройдёт Saint HighLoad++ 2026. Я там буду и планирую походить на доклады. Вообще, в этом году ну очень много докладов про ИИ, внедрении ИИ и проечее ИИ. Я насчитал 20 из 50 докладов. Т.е. больше 1/3, что дофига для конференции про высокеи нагрузки. А про ахитектуру всего 1 доклад, 1 воркшоп, и игра по System Design (что, кстати, очень интересно, жаль я не смог поучасвовать в отборе). Вот мой топ докладов, которые хочу послушать: Я люблю копаться в кишках баз данных, по этому воркшоп "Допиливаем свой форк Постгреса свистелками" хочу посетить и попробовать собрать что там получится. Мне часто приходится дебажить агентов, когда сам пишу с их помощь, по этому воркшоп "Смотри, как думает агент: Observability AI-агентов с Langfuse" выглядит очень привлекательным. Схожу на доклад Ивана Поддубного "Уровни зрелости внедрения AI в процессы разработки", поскольку часто сам вижу внедрения ИИ в команды и, чаще всего, очень топорное. Послушаю "Как жить без строгой консистентности и не терять деньги", надеюсь это не доклад-пересказ документации. Автор доклада из финтеха, интересно как финтех уживается с evantual consistency. А если и вы будете на конфе, то подходте поболтать и обсудить доклады и воркшопы.🫰

Привет, мои юнные архитекторы. 👨‍💻 Сегодня я хоче разобрать с вами задачу из System Design Interview. Будем проектировать платёжную систему. В чём интерес в такой системе? В первую очередь в том, что мастшабирование тут вообще не первостепенно. Везде, где есть деньги, важна исключительная надёжность 🤑 Го читать — https://teletype.in/@mifleo/payment-system-design А потом давайте обсудим в комментариях! ⸻ Давайте оставаться на связи

Привет! 📞 Я иногда разгоняю на софтовые темы, сегодня хочу поговорить о внедрении изменений. Предположим, ты в своей команде ты видишь какой-то процесс, который нужно изменить или изменений пришли "сверху" и нужно их произвести у себя, или это какие-то вынужденные меры. Для каждого случая может потребоваться своя стратегия. Вообще, тема внедрения изменений достаточно объемная и глубокая. От неверно выбранной стратегии даже хорошие изменения часто загибаются. Самый простой способ: директивно "спускаем" своё решение.

"Команда, со следующего вводим WIP-лимиты".

Даже у понимающих и лояльных сотрудников начинается отрицание, потому что никто не любит перемены. Так устроена челочечиская психика. А не понятные перемены мы не любим ещё больше. Лучшим исходом будет, что, пока ты следишь за процессом и контролируешь его, оно как-то работает. Как только контроль ослабляется, то процесс уходит на помойку. С дугой стороны, очень легко наткнуться на протест. Молчаливый или открытый. Или саботаж. И ты можешь подумать, блин, ну все же знают, что дают WIP лимиты. Ограничиваем и выравниваем поток, делаем контролируемую поставку. Чё они сопротивляются-то? Я же знаю, как лучше будет. Конечно, далеко не все знают о лимитах и об их пользе, что они делают и зачем. Конечно, совершенно точно, никто не знает твою цепочку рассуждений, какую проблему ты хочешь решить и почему именно так. Самое постое лечение тут, это развенуть принятие решение в сторону: "Команда, я вижу проблему, что тестирование захлёбывается в задачах" или "задачи скапливаются в код ревью и не двигаются дальше, что будем делать?". Идеально, когда решение формулиуется всей командой даже если ты его знаешь. Так решение становится общим и понятны, и его морально легче принять. У процесса должен быть владелец. Классно, если у изменения был какой-то противник и его удалось перетащить на свою сторону, если назначить этого бывшего противника смотреть за новым процессом ты выигрываешь комбо: противник становится адпетом и новый процесс остаётся под присмотром. Окей, а как понять, что это изменение реально что-то сделало лучше? Это важный поинт. Во-первых, нужно измерять. Перед началом улучшения прикинь текущую точку А и куда в итоге хочется прийти, как понять что мы пришли и как это померять. Можно вести дневник по внедрению изменения. Записывать что стало лучше, что хуже и т.д. Такой подход будет работать и для не крупных инициатив внутри команды. А в следующей заметке я расскажу как внедрить крупное изменение. Обсудим? ⸻ Давайте оставаться на связи

Всем привет. Продолжаю делиться нетленной классикой. На очереди «Чистый код» — одна из самых известных книг о качестве кода. Её часто советуют джунам как обязательную базу, но нормально читается и осознаётся она как раз после того, как у тебя уже были реальные проекты, легаси, спорные ревью и функции на несколько экранов. Мартин разбирает повседневные вещи: имена переменных и функций, размер методов, комментарии, форматирование, обработку ошибок, тесты, классы, границы модулей, работу с чужим кодом. Буд-то и ничего прям нового. Но ценность книги как раз в том, что она заставляет внимательнее смотреть на мелкие решения, из которых потом собирается общая сложность проекта. Главная мысль, которую я забрал из книги: код читают чаще, чем пишут. Я убеждён, в том числе и это отличает грейд разработчика: писать код для чтения. Любой участок, который сегодня кажется очевидным, через полгода превращается в задачу на археологию, если в нём спрятаны неявные допущения, странные имена, побочные эффекты и логика, размазанная по нескольким уровням. Хорошее (говорящие) имя функции, переменной или класса должно сокращать количество вопросов у читателя. Прямо помогать понять, что происходит и зачем. Если название врёт, слишком общее или требует знания контекста из головы автора, оно уже создаёт долг. Отдельно полезны главы про функции. Мартин довольно сильно продвигает идею маленьких функций с одним уровнем абстракции. С этим можно спорить, особенно в современных проектах, где чрезмерная нарезка иногда ухудшает навигацию. Но сама проверка полезная: функция должна быть понятна как единый шаг алгоритма. Если внутри смешаны валидация, бизнес-логика, работа с БД, форматирование ответа и логирование, сопровождение быстро дорожает. Кстати, комментарии в книге разобраны хорошо. Идея Мартина в том, что комментарий не должен компенсировать плохой код. Если можно выразить намерение через имя, структуру или тип, лучше сделать это в коде. Комментарии нужны там, где без них нельзя объяснить контекст, ограничение, компромисс или неочевидное решение. С тестами позиция тоже понятная: тестовый код — часть системы, а не мусор рядом с ней. Если тесты хрупкие, нечитаемые и требуют постоянного переписывания при любом изменении, команда постепенно перестаёт им доверять. Это один из самых практичных тезисов книги: плохие тесты не спасают качество, они сами становятся источником энтропии. При этом книгу не стоит воспринимать как набор законов. (как и любую другую, кстати) Некоторые советы выглядят слишком категорично. Например, идеи про экстремально маленькие функции, отказ от комментариев или отдельные ООП-подходы могут плохо ложиться на конкретный стек, стиль команды или доменную сложность. «Чистый код» полезнее читать не как инструкцию, а как набор инженерных проверок: что усложняет понимание, где спрятан побочный эффект, почему этот участок страшно менять. Мой основной вывод: чистота кода — это скорость безопасных изменений. Код может работать сегодня, проходить тесты и даже выглядеть аккуратно, но быть дорогим в сопровождении. Проверка кода начинается тогда, когда приходит новое требование, меняется бизнес-правило или разработчик без контекста должен быстро внести правку. Читать лучше не залпом, а с примеркой на свой код. Взял главу про функции — открыл пару рабочих классов и посмотрел, где смешаны уровни абстракции. Прочитал про имена — прошёлся по DTO, сервисам, методам и тестам. Так книга даёт больше пользы. Хотя сам я её прочёл залпом. Итог: «Чистый код» стоит прочитать, но без религиозного отношения. В ней есть спорные места, возрастные примеры и категоричные формулировки. Но базовый навык, который она тренирует, до сих пор важен: смотреть на код глазами человека, который будет его читать, менять и отвечать за последствия этих изменений. Обсудим? ⸻ Давайте оставаться на связи

Привет, мои юнные архитекторы. Обычно кэш в мы используем для ускорения чтения. Да? 😄 Схема такая:

read from Redis
if miss -> read from PostgreSQL/MySQL
put result to Redis

При изменении данных приложение пишет в базу, а кэш инвалидирует или обновляет. Это обычный cache-aside. "Правда" остаётся в базе. Потеря кэша в такой схеме неприятна, но не приводит к потере бизнес-данных. Но есть и другой вариант: приложение сначала пишет данные в ин-мемори (напиме, редис), быстро подтверждает операцию клиенту, а потом отдельный процесс асинхронно переносит изменения в постоянное хранилище. Такой подход обычно называют: • write-behind cache; • write-back cache; • cache-first write path; • буферизация записи через Redis. Схема выглядит просто:

PHP application
  -> Redis
  -> async worker
  -> PostgreSQL/MySQL

Быстрая запись, меньше нагрузки на базу, возможность переживать пики и флашить данные пачками. Но при таком write path Redis становится частью механизма хранения, а не просто ускорителем чтения. Можно ли это вообще называть кешом теперь? Кэш как часть write path Кэш можно удалить и восстановить из основного хранилища. Если после потери Redis теряются подтверждённые пользователю действия, Redis используется уже как write buffer или временное хранилище. Для такой роли нужны другие требования: - durability; - порядок применения изменений; - идемпотентность; - восстановление после сбоев; - контроль backlog; - backpressure. Название “кэш” в этом месте часто мешает. Оно создаёт ощущение, что слой можно потерять без последствий. Для cache-first систем это неверно. Рассмотрим, где cache-first подойдёт. Такой подход может работать для данных, где допустима eventual consistency и ограниченная потеря части событий. Например: - просмотры; - лайки и реакции; - rate limiting state; - сессии; - временные агрегаты; - игровые события; - телеметрия; - clickstream; - промежуточное состояние, которое можно пересчитать. В этих сценариях write-behind может быть нормальным компромиссом между скоростью записи и строгостью гарантий. Для денег, заказов, остатков, прав доступа, юридически значимых действий и сложных бизнес-инвариантов такой подход требует отдельного обоснования. Чаще всего безопаснее писать сначала в durable storage или durable log. Основной риск: окно между Redis и базой Пример на PHP:

$redis->hSet("user:{$userId}", 'email', $newEmail);

$redis->rPush('pending_writes', json_encode([
    'operation_id' => $operationId,
    'type' => 'user_email_changed',
    'user_id' => $userId,
    'email' => $newEmail,
]));

return new JsonResponse(['status' => 'ok']);

Клиент получил 200 OK. Постгрес ещё не обновлён. Изменение находится только в Redis и будет применено позже фоновым воркером. Для такой схемы нужно заранее ответить на несколько вопросов: - что произойдёт при падении Redis до flush в PostgreSQL; - включён ли AOF; - какой режим appendfsync используется; - что будет при failover до репликации; - как воркер поймёт, что запись уже применена; - что произойдёт при повторной обработке операции; - как сохраняется порядок изменений по одной сущности; - откуда система будет восстанавливаться после аварии. Без ответов на эти вопросы клиентский 200 OK означает только успешную запись в буфер, а не сохранность данных. Потеря подтверждённых записей Если запись подтверждена клиенту после Redis, но до PostgreSQL не дошла, сбой Redis может привести к потере данных. Для счётчиков или аналитики это иногда допустимо. Для смены email, оплаты, бронирования или изменения прав — обычно нет. Тут важно понять, а какие у нас гарантии записи? Если бизнес-смысл операции требует сохранности, подтверждать её после записи только в Redis такое себе решение. Redis может быть быстрым буфером, но сама операция должна иметь durable-точку: базу, журнал, очередь или другой устойчивы страдж. Если ты думаешь "Ну, сначала пишем в Redis, потом воркер переложит в базу.", то кое-что от тетбя ускользает 😀 Продолжу с ледующем посте🔤 ⸻ Давайте оставаться на связи

Привет. Видели уже RFC по дженерикам в php? В PHP обсуждают RFC Bound-Erased Generic Types — попытку добавить нативные generics: Box<T>, Repository<User>, function map<T>(). Сейчас generics в PHP живут в PHPDoc в рамках статанализаторов или пхп шторма:

/**
 * @template T
 * @param T $value
 * @return T
 */
function id($value) {
    return $value;
}

RFC предлагает перенести это в синтаксис языка:

function id<T>(T $value): T {
    return $value;
}

final class Box<T> {
    public function __construct(public T $value) {}
}

Классно, что появится общий подход вместо абстрактного @template в phpdoc для станализаторов. RFC даёт общий синтаксис, bounds, defaults, variance и Reflection metadata:

final class Repository<T : Entity> {}

final class Cache<K = string, V = mixed> {}

interface Producer<+T> {}
interface Consumer<-T> {}

Для крупных проектов и библиотек это полезно: generic-контракт становится частью API, а не комментарием рядом с ним. Но подход спорный. Очень. Это bound-erased generics. Type parameter в runtime стирается до своего bound. Если bound не задан — до mixed.

function id<T>(T $value): T {}

Здесь T в runtime фактически превращается в mixed.

function save<T : Entity>(T $entity): void {}

Здесь T стирается до Entity. Совсем не то, чего хотелось бы, правда? Короче, конкретный type argument не становится полноценной runtime-проверкой.

final class Box<T : object> {
    public function set(T $value): void {}
}

$box = new Box::<User>();
$box->set(new Order());

Если Order — объект, runtime может это принять. С точки зрения Box<User> это ошибка, но ловить её должен static analyzer. Ещё неприятнее выглядит такой пример:

function id<T>(T $value): T {}

id::<int>("hello");

Вы могли подумать, что ::<int> должен запретить строку. Но RFC описывает другое поведение: turbofish проверяет generic-аргумент, arity и bounds, но не ужесточает runtime-тип параметра. Если T стёрся до mixed, строка пройдёт. Я работал с языком, когдам никакой типизации небыло вовсе, а в последние годы язык усиливал runtime-типизацию: scalar types, return types, union/intersection types, typed properties, readonly. Я как разработчик привык: если тип написан в сигнатуре языка, движок его проверяет. С generics по этому RFC вообще не так. Синтаксис выглядит как часть языка, но значительная часть гарантий остаётся на стороне стат анализа (который не часть языка совершенно). Если не обмазаться статанализом, то чуда не случится. Ещё один минус для меня — RFC не закрывает самый частый PHP-сценарий:

/** @return list<User> */
/** @param array<string, Order> $orders */

array<int, string>, list<User>, non-empty-list<User> в этот RFC не входят. А именно массивы — главный источник generic-аннотаций в обычном коде. В общем, RFC прикольный как стандартизация @template и база для тулинга. Он улучшит контракты для стстанализа, Reflection и публичные API библиотек. Но как полноценные дженерики в языке подход кастрированный. Box<User> не становится железным runtime-контрактом. Runtime проверяет bounds, а не полную параметризацию. Вообще, если примут, имхо, получается очень фиговая комбинация: - синтаксис как у языка - семантика как у комментариев - обязательного чекера нет - runtime-проверка частичная Обсудим? ⸻ Давайте оставаться на связи

Привет! Решил я ввести рубрику обзора книг. И начать хочу с классики. До этой книги я не мог добраться несколько лет, отпугивал внушительный размер. Возил с собой в рюкзаке в метро больше года, за это время она заметно истрепалась снаружи, хотя ни строчки я не прочёл. А когда прочёл, расстроился, что не сделал этого раньше, потому что до многих идей в книге я дошёл через опыт, через грабли, через другие книги. Вообще, я всегда увлекался архитектурой, чистым кодом, качеством разработки. Это особенно актуально сейчас, когда код руками код пишут всё меньше, а разбираться в архитектуре нужно всё больше. Моё резюме: «Совершенный код» — большая инженерная книга о повседневной разработке. Макконнелл разбирает не только сам код, но и весь контекст вокруг него: подготовку к реализации, декомпозицию, именование, функции, классы, условия, циклы, обработку ошибок, отладку, тестирование, ревью и рефакторинг. Книга местами ну оооочень подробная. Некоторые примеры выглядят даже устаревшими, потому что писалась она в другую эпоху разработки. Но большая часть идей спокойно пережила смену языков, фреймворков и инфраструктуры. А всё потому что сложность кода никуда и не делась. Мы всё так же читаем чужиой код, а сейчас даже больше, чем раньше, пытаемся понять условия, боимся сломать соседний сценарий и платим техдолг, накопленную годами. Главная мысль, которую я забрал из книги: качество кода складывается из множества маленьких решений. Название переменной, размер функции, глубина вложенности, явность условий, способ обработки ошибки, граница класса, форма интерфейса — всё это потом определяет, насколько дорого будет менять систему. Хороший код помогает следующему разработчику быстро восстановить намерение автора. И чаще всего этим следующим разработчиком окажешься ты сам через несколько месяцев. Если для понимания участка нужно держать в голове десять неявных допущений, то это плохо написанный, даже если код формально работающий, код. Ещё один важный вывод: простота требует дисциплины. В реальных проектах легко начать строить универсальность заранее, добавлять абстракции на будущее и прятать бизнес-смысл за слоями технической красоты. Макконнелл хорошо возвращает к базовой проверке: насколько быстро человек поймёт этот код и насколько безопасно сможет его изменить. Отдельно полезны главы про defensive programming, ревью и рефакторинг. Там хорошо видно, что качество — это не самоотверженность отдельного разраба. Нужны командные договорённости: стандарты, ревью, тесты, регулярная чистка мёртвого кода, нормальная работа с техническим долгом. Без этого кодовая база постепенно становится вязкой, даже если её пишут сильные инженеры. Кому рекомендую: ➖ junior-разработчикам 👶 — чтобы раньше набрать правильные инженерные привычки; ➖ middle-разработчикам 👦 — чтобы лучше видеть источники сложности в своём коде; ➖ senior-разработчикам 👨‍🦱 — чтобы точнее формулировать замечания на ревью; ➖ тимлидам и архитекторам 👨‍🦳 — чтобы не сводить качество системы только к диаграммам и выбору технологий. Кстати, читать прям подряд все главы не обязательно. Книга пугающе большая, и не все главы одинаково нужны прямо сейчас. Я бы начал с тем про именование, функции, классы, ошибки, тестирование, ревью и рефакторинг. Дальше — возвращался бы к ней как к инженерному справочнику. «Совершенный код» полезен тем, что прокачивает взгляд на код как на долгоживущий инженерный артефакт. Недостаточно, чтобы он просто выполнялся. Важно, чтобы его можно было понять, безопасно изменить и передать другому человеку без устного фольклора вокруг каждой строки. Читали эту книгу? Что думаете? ⸻ Давайте оставаться на связи ☄️

Last Call 📞 Привет. Ребята, сегодня в 19-00 стартуем наш воркшоп по АИ кодингу! Провели много подготовки и покажем классные иструменты, с помощью которых ты уже не "оператор ЛЛМ", а полноценный рахрабочтик с мощным инструментом в руках. Я давно и много говорю, что важно понимание работы с агентами и контроль результата. И мы этим займёмся. Информации сейчас много, она быстро устаревает, по этому это отличный шанс получить чистую практику, которую можно адаптировать под свои задачи. Вот тут программа воркшопа и все подробности. Увидимся!

Приветик! В блоге у Мартина Фаулера вышла статейка про ИИ кодинг, подход называется Structured-Prompt-Driven Development. SPDD — это подход к разработке с AI-ассистентами, где промпт перестаёт быть одноразовым сообщением в чат. Промпт становится полноценным артефактом разработки: — хранится рядом с кодом; — версионируется; — проходит ревью; — переиспользуется; — обновляется вместе с изменениями в коде; — фиксирует не только задачу, но и требования, доменную модель, архитектурные ограничения, шаги реализации и правила безопасности. В статье я вижу близкую мне мысль: AI хорошо ускоряет отдельного разработчика, но это не гарантирует ускорение всей команды. Писать код стало быстрее. Понимать, что именно мы пишем, ревьюить изменения, держать архитектурные границы и не тащить в проект случайные решения — проще не стало. SPDD как раз про этот разрыв. В статье предлагается REASONS Canvas — структура для подготовки промпта: — Requirements — требования и Definition of Done; — Entities — доменные сущности и связи; — Approach — выбранный способ решения; — Structure — место изменения в системе; — Operations — конкретные шаги реализации; — Norms — инженерные правила; — Safeguards — ограничения, которые нельзя нарушать. Перед генерацией кода мы явно собираем контекст, в котором модель должна работать. Запросы уровня «напиши мне фичу» не дадут желаемого результата. А «вот требования, вот домен, вот архитектурные границы, вот способ решения, вот правила проекта, вот что нельзя ломать». Статью эту я увидел только сегодня, но это капец как близко к тому workflow, который я последние месяцы собирал для AI-кодинга. И мысли мне очень сильно откликаются. У меня это оформлено не как REASONS Canvas, а как набор скилов и оркестратор: — скилл для анализа задачи; — скилл для архитектурного решения; — скилл для проектирования API и OpenAPI-спеки; — скилл для выделения доменной модели; — скилл для декомпозиции задачи; — скилл для проверки quality gates; — скилл для поиска DTO leakage, нарушения границ и архитектурных расхождений. Плюс тесты для самих скилов. У Фаулера это описано как structured prompts, REASONS Canvas, version control, review, safeguards и quality gates. В моём workflow — скилы, архитектурный baseline, оркестратор, проверки границ и тестовые сценарии. Разные реализации, но идея одна: AI-кодинг нужно вытаскивать из режима «поболтал с моделью и получил diff» в нормальный инженерный процесс. Именно про это будет наш воркшоп. Кстати, продажи уже открыты, сам воршоп пройдёт 5️⃣ мая! 🔥 Если хочешь разобраться в AI-кодинге на уровне инженерного процесса, а не набора удачных промптов — регистрируйся в боте. 🎟

Как я не запустил свой стартап, но прокачался в AI-кодинге Периодически вижу ролики в духе: «человек без технического бэкграунда за вечер собрал стартап с помощью AI». Выглядит эффектно, но я таким историям не очень верю. Собрать демку сейчас действительно стало сильно проще. Но довести её до состояния продукта — уже другая задача. Там быстро появляются требования, данные, архитектура, интеграции, ошибки, тесты, странные сценарии и необходимость понимать, что именно ты построил. В какой-то момент я тоже решил попробовать сделать небольшой продукт. У меня давно была идея сервиса для ЖКХ-квитанций. Я не люблю вручную разбирать платежки, сравнивать показания, искать, почему сумма выросла, и вспоминать, что было месяц назад. Хотелось сделать простой сценарий: сфоткал квитанцию → прогнал через OCR → получил JSON → увидел графики, изменения и короткое объяснение. Под это я даже написал и выложил в open source библиотеку для работы с Yandex OCR. Дальше всё пошло ожидаемо криво. У квитанций нет нормального единого формата. В одном файле таблица читается нормально, в другом съезжает разметка, в третьем OCR путает поля, в четвёртом одинаковые на вид строки означают разные вещи. Через пару недель стало понятно, что каждый новый формат квитанции придётся отдельно допиливать. Продукт как идея мне всё ещё нравился, но поддержка такого зоопарка быстро съедала весь интерес. Зато сам проект оказался хорошей площадкой для экспериментов с AI-кодингом. В нём были неполные требования, доменная модель, API-контракты, интеграции, обработка ошибок, тесты и постоянный риск развалить архитектуру после очередной генерации кода. Сначала я просто сохранял удачные промпты. Потом начал оформлять их как скилы. Потом стало понятно, что один скилл не должен пытаться делать всё сразу. Так постепенно появился набор: — скилл для архитектурного решения по задаче; — скилл для проектирования API и генерации OpenAPI-спеки; — скилл для выделения доменной модели; — скилл для декомпозиции большой задачи; — скилл для проверки результата через quality gates; — скилл для поиска нарушения границ и архитектурных расхождений. — и другие. Отдельно появился оркестратор, который прогоняет задачу по этапам: анализ, архитектура, контракты, проверка консистентности, подготовка реализации. Самое интересное началось, когда я дошёл до тестирования скилов. Например, тестовый сценарий может выглядеть так:

{
  "skill": "review-architecture-boundaries",
  "mode": "should_trigger",
  "query": "Review this diff against the architecture baseline for boundary violations and DTO leakage.",
  "expected_reason": "Boundary review against an existing baseline."
}

Так можно проверять, когда скилл должен сработать, когда не должен, какой результат ожидается и какие ошибки он обязан поймать. Получается почти TDD для AI-скилов. В итоге сервис для квитанций я не запустил. Но за время разработки собрал нормальный практический опыт по AI-кодингу: скилы, декомпозиция, оркестрация, quality gates, тестирование и работа с агентом на проекте, где есть архитектура, API, доменная модель и код. Этим и хочу поделиться на воркшопе. Разберём: — как проектировать скилы под реальные задачи разработки; — как дробить большую задачу для агента; — как собирать workflow из нескольких скилов; — как уменьшать галлюцинации и несостыковки; — как проверять результат через quality gates; — как тестировать поведение скилов; — как встроить всё это в обычную разработку. Если тема близка — регистрируйся. Скоро стартуем 🔥

Всем привет! В прошлом году, я давал интервью про себя и рассказывал про то, как попал в IT и вообще. Делился с вами, что не умею и не люблю давтаь интервью и говорить о себе. Мне проще поумничать о чём-то. А не так давно, меня позвали на подксат @psyvit тоже порассказывать про себя. И мне понравилось. Было душевно и лего. Обсудили культ "сильного лида", боязнь ошибок, важность быть честным и открытым с командой и, конечно же, как выжить молодому лиду. Послушать можно тут.

Привет. Хочу снова коротко рассказать про подготовку к system design interview. За последнее время ко мне несколько раз приходили почти перед самым собеседованием. Ситуация обычно одна и та же: времени мало, в голове что-то есть, но целостности и уверенности нет. Это знакомая история. Можно знать основные компоненты, читать про распределённые системы, в целом понимать, как собирается архитектура, и всё равно теряться на интервью. Где-то человек слишком рано проваливается в детали, где-то не успевает договориться по требованиям, где-то просто не держит темп ответа. У меня самого это тоже было. В работе я мог рассуждать про систему нормально, но на интервью постоянно не укладывался и смазывал ответ. В какой-то момент я пошёл к ментору, и он очень хорошо подсветил мои слабые места: как держать тайминг, в каком порядке идти по задаче, где не залипать, какие вопросы лучше прояснить в самом начале. После этого я собрал себе небольшую шпаргалку в Obsidian и какое-то время реально на неё опирался. Потом появилась мысль дособрать её в более цельный материал. В итоге из личной заметки вырос гайд по подготовке к system design interview: с опорой на структуру ответа, набор типовых компонентов, паттерны, контрольные вопросы и ориентиры, которые помогают не рассыпаться по дороге. Сейчас я его ещё докручиваю и обкатываю. Если у вас впереди system design interview или просто хочется привести знания в более собранный вид, пишите в личку, буду рад помочь!

Всем привет! Я несколько раз выступал на Podlodka PHP Crew (записи публиковал в канале), но в этот раз хочу просто рассказать о том, что совсем скоро будет очередной сезон. Каюсь, я давно уже не пишу код на php, но всегда слежу за стеком и обновлениями. Я думаю, что все уже заметили насколько сильно изменился стек современного php разработчика. И вот, ребятки из Podlodka PHP Crew собрали онлайн-конференцию «Современный стек PHP-разработки», чтобы разобраться, как всё устроено сегодня. 🗓С 20 по 24 апреля участники: • изучат, как сегодня запускают PHP-приложения (worker mode, новые рантаймы, FrankenPHP), • посмотрят, как изменилась инфраструктура и что пора выкинуть из Docker-стека, • обсудят, как реально применять AI-агентов в разработке (не только писать код, но и расследовать баги и планировать изменения), • разберут практические кейсы (например, в онлайн-режиме будут запускать мультиплеерную игру на PHP с Temporal и RoadRunner), • и в целом поймут, какие инструменты и подходы действительно стоит внедрять в 2026. Формат — пять дней живых Zoom-сессий по утрам и вечерам, закрытое комьюнити в Telegram и общение со спикерами. Если хотите обновить свой стек и лучше понимать, куда движется разработка на PHP — обязательно присоединяйтесь👇 🎟Подробности и билеты По промокоду php_crew_8_7PT0Qe получите сикду🎁 ⚠️По традиции, я разыграю один белетик среди подписчиков. Думал как и придумал (но не сделал). По этому разыграю среди тех, кто прокомментирует эту публикацию и, конечно, будет подписан на канал. Итоги подведу 18.04 т.е. в субботу 💚

Приветик! Недавно вступил в дискуссия у одного автора в комментариях под постом про событийно ориентированную архитектуру. Причиной спора стало куда складывать логику обработки. Но давайте разберемся вообще что за архитектура такая и как это реализовать. Проблема: У нас есть некоторая доменная сущность Order, она же заказ. Со временем она неизбежно обрастёт разными "последствиями": обновить скидку клиенту, когда заказ выполнен, отправить сообщение, когда заказ передан в доставку, переслать заказ в CRM и т.д. Знакомо? Уверен, что да. Пока завязок не так много, всё идёт хорошо. Потом простыня из этих последствий разрастается. Кто-то ещё умудряется и всякие условия выносить. Типа

if ($orders->isPaid()) 
{
 $this->emailService->sendNotification();
}

Почему это проблема? Метод разрастается, обрастает зависимостями и связанностью. Изменение этого метода заставляет проверять всю цепочку, друг там что-то сломалось. Решение: Развязать эти методы. Система создаёт некоторое событие, наступление которого вызывает цепочку реакций. В коде обычно это выглядит так:

 $event = new OrderPaidEvent($orderId);
 $this-eventDispatcher->dispatch($event);
 
 ....
 
 final class OrderPaidHandler implements EventHandler
 {
  public function handle(DomainEvent $event): void
  {
  }
 }

Связанность кода в такой реализации значительно падает, а расширение функциональности становится сильно проще: просто добавляется новый хандлер и всё. Остальной функционал не изменялся. Как делать не нужно. Не нужно засовывать всё в один хандлер. Делать события просто потому что уже где-то есть сбытия. Не нужно забывать, что событие триггерится за рамками транзакции, а не внутри. Возвращаясь в начало, в чем же был предмет нашего спора? В том, где должны располагаться "последствия" события, которые работают в слое приложения. Стригерило меня предложение доменную логику ловить в хандлере, а логику пиложения (типа отправки имейла) оставлять рядом с самим триггером. Я вижу в этом проблему: код расползается, часть логики оформлена одним образом, часть другим. Это делает поддержку дороже, вход в приложение нового разработчка — сложнее. Да и для ИИ это тоже проблема. Нужны какие-то понятные критерии, чтобы объяснить своему ИИ джуну, что нужно ложить рядом, а что в хандлер заворачивать. Короче, наш путь это единообразие. ⸻ Давайте оставаться на связи ☄️

Привет. Я тут снова про ИИ. 📱 А вам всё ещё кажется, что модели недостаточно умны? Или что модели недотягивают чтобы делать твои задачи? Я так не думаю. У современных моделей очень обширные возможности. В реальности, большинство ограничений лежит в навыках конкретного разработчика планировать и ставить задачу под LLM. По факту, если ваша моделька галлюцинирует, теряет контекст, работает не в ту сторону, выдаёт другой результат — почти всегда проблема в оркестрации, постановке задачи, инфраструктуры вокруг ИИ. ИИ это только инструмент в твоих руках, при чём инструмент очень мощный. Осталось освоить как им пользоваться. Для хорошей работы нужно всего-то: дать на вход качественную спеку, дать модельке нужную декомпозицию, возможность самой модели делить задачу на кусочки и рекурсивно вызвать субагентов для итеративной разработки. Данил Щуцкий, например, для подобных целей сделал Ai Factory — инструмент для построения воркфлоу для разработки. Я же собрал свой ворклфоу самостоятельно и дорабатываю его от задачи к задаче, делая его надёжнее и лучше. В общем, это заход на наш второй AI workshop. Скажу прямо, воркшоп не для новичков. На нём мы расскажем и покажем как построить свой workflow, как работать с оркестрацией, субагентами, как работать с MCP и создавать собстенные. 👉 За подробностями заходите сюда!