Организованное программирование

В этом выпуске я решил немного отойти от привычного формата разговоров с гостями и записал сольный эпизод. Последний год я довольно глубоко погружён в тему AI: активно использую его в разработке, экспериментирую с агентами, внедряю в рабочие процессы и параллельно готовлю образовательные программы про работу с LLM. За это время накопилось много наблюдений — как технических, так и организационных, которыми мне захотелось поделиться.Мы поговорили о том, что на самом деле происходит с индустрией разработки. Почему вокруг технологий возникает ощущение тревожности и гонки вооружений, и как меняется работа инженера - от привычного “чат-ассистента” к агентской разработке, от ручного кодинга к управлению системой инструментов.Отдельная часть выпуска — про знания и фундаментальные навыки. Я разобрал популярную идею о том, что «алгоритмы и фундамент больше не нужны», объясняю эффект проклятия знания и рассказываю, почему архитектурное мышление и способность формулировать задачу на уровне системы становятся ещё важнее в эпоху LLM. На реальных примерах из собеседований показываю, как отсутствие этой картины ломает работу даже с очень мощными инструментами.Также обсудили архитектурные подходы для эпохи AI-разработки: концепцию барьеров абстракции, изолированные компоненты, которые можно безопасно генерировать целиком, и баланс между «вайб-кодингом» и инженерной дисциплиной. Я делюсь примерами из реальных проектов — от генерации React-компонентов до автоматизации инфраструктуры вокруг n8n, тестов и рефакторинга больших кодовых баз.🔹30 марта стартует курс по эффективной разработке с помощью ИИ, присоединяйся -  https://ru.hexlet.io/programs/ai-for-developersПодписывайтесь на канал «Организованное программирование» в Telegram: https://ttttt.me/orgprog– Список подкаст-платформ (Apple Podcast, Google Podcast, Spotify, Яндекс.Музыка и другие): https://podcast.ru/1734325321– Смотреть в ВК Видео: https://vkvideo.ru/video-224967259_456239249🔹 Telegram-канал Организованного Программирования: https://t.me/orgprog🔹Хекслет Клуб в Telegram https://t.me/HexletClubBot🔹Курсы по программированию — начни учиться уже сегодня: https://ru.hexlet.io/courses#искусственныйинтеллект #ai #программирование #разработка #chatgpt #aiразработкаЧто я понял после года разработки с помощью ИИ агентов / Кирилл Мокевнин (00:00) - - Введение. честный разговор про ИИ без гостей (00:30) - - Год жизни с ИИ: внедрение, эксперименты и обучение других (05:15) - - Когда ИИ превращается в игру для программистов (10:38) - - Изменятся ли знания программиста из-за ИИ (17:48) - - Почему ИИ не делает программиста умнее (25:10) - - Какие навыки программиста точно останутся важными (34:01) - - Главная проблема ИИ: он лечит симптомы, а не причину (43:06) - - Когда правила начинают ломать проект (54:15) - - Ошибка ИИ: тестирование HTML в тестах (01:04:12) - - Новый стиль функций в эпоху ИИ (01:16:22) - - Заключение. Почему скилы от компаний могут ломать ваш проект ★ Support this podcast ★

Мы продолжаем разбираться в Domain-Driven Design — на этот раз прямо на уровне кода. Несколько недель назад мы с Евгением Лукьяновым делали EventStorming для идеи сервиса аналитики Telegram-каналов: системы, которая парсит каналы, анализирует посты, считает метрики и помогает авторам понимать, о чём писать и какие темы заходят.Евгений — технический директор компании Satory и автор образовательного проекта StreamConcat. Он много лет работает с DDD и чистой архитектурой и строит на этих принципах коммерческие системы. Поэтому вместо абстрактных рассуждений мы открыли редактор и начали разбирать, как события, агрегаты и инварианты из EventStorming превращаются в Kotlin-код на Spring Boot.Полезные ссылки:https://t.me/stringconcathttps://www.youtube.com/@UCJ2Tig1kywPjqjNh0mb54Ug Подписывайтесь на канал «Организованное программирование» в Telegram: https://ttttt.me/orgprog– Список подкаст-платформ (Apple Podcast, Google Podcast, Spotify, Яндекс.Музыка и другие): https://podcast.ru/1734325321– Смотреть в ВК Видео: https://vkvideo.ru/video-224967259_456239248🔹 Telegram-канал Организованного Программирования: https://t.me/orgprog🔹Хекслет Клуб в Telegram https://t.me/HexletClubBotВ этом выпуске:— как из стикеров EventStorming получается структура домена— почему агрегаты и доменные события часто реализуют без ORM— как выглядит минимальный каркас DDD-приложения: entity, aggregate root, value object— зачем хранить события внутри сущностей и как потом их «вынимать»— как устроены use case-слои и почему бизнес-логика должна жить внутри домена— где заканчивается доменная модель и начинается инфраструктура— как связывать агрегаты через события и слушатели— транзакции, outbox-паттерн и обработка доменных событий— почему вокруг DDD так много споров и где инженеры видят оverengineering\#DDD #EventStorming #архитектура #программирование #разработкаПО #организованноепрограммирование #кириллмокевнин Чистая архитектура и Domain Driven Design на практике | Евгений Лукьянов №77 (00:00) - - Введение. Можно ли превратить DDD из теории в реальный код? (02:45) - - Идея стартапа: AI-сервис для анализа Telegram-каналов и поиска тем для постов (08:51) - - Главные сущности проекта: канал, пост и тематика (17:10) - - Демонстрация логики агрегатов (27:45) - - Базовые типы: ID, строковые ограничения и value-объекты (38:15) - - Бизнес-ошибки против исключительных ситуаций (46:26) - - Live-валидация на фронтенде и UX (59:22) - - Когда безопасность требует дополнительных проверок (01:09:57) - - Зачем использовать Mock в тестах (01:21:19) - - Проблема уникальности в нагруженных системах (01:28:08) - - Когда DDD действительно спасает архитектуру (01:37:37) - - Vibe coding и парное программирование с AI (01:51:33) - - Транзакции и работа с Postgres (02:01:56) - - Заключение. DDD vs классическая архитектура ★ Support this podcast ★

В этом выпуска у нас в гостях Алексей Солодкий, инженеринг-менеджер и бывший руководитель разработки BelkaCar. Человек, чья карьера практически совпала с расцветом микросервисной архитектуры: от раннего энтузиазма «пилить всё на сервисы» до болезненного переосмысления и обратного движения к более прагматичным решениям.Мы детально прошлись по  микросервисам - где они действительно решают проблему, а где создают новые? Почему семь инженеров и «монолит — это злое зло» — плохая отправная точка для архитектурных решений? И правда ли, что средний монолит стабильнее средних микросервисов?В выпуске:— как 200 бэкендеров контрибьютили в один монолит в Badoo и при этом релизились дважды в день— что такое «распределённый монолит» и почему это худшее из двух миров— как микросервисы превращаются в культ карго и начинаются «роликом на YouTube»— синхронная vs асинхронная коммуникация: где действительно нужен event bus, а где подойдет обычный HTTP — идемпотентность, сетевые таймауты, “exactly once” и иллюзии, в которые верят инженеры— graceful degradation и как проектировать систему так, чтобы она жила без части своих сервисов— observability, трейсинг, метрики и реальная стоимость прозрачности— зачем API нужно проектировать под клиента, а не под внутреннюю структуру сервисов— почему иногда правильнее «монолитить» обратноОтдельно обсудили болезненную тему: микросервисы требуют гораздо более высокой квалификации, чем кажется. Писать отдельный сервис просто. Построить устойчивую распределённую систему — нет. Цена ошибки здесь выше, чем в монолите, а переделывать разрезы между сервисами крайне дорого.Полезные ссылки:YouTube - https://www.youtube.com/playlist?list=PLZVF-B6xjrIuX-gMghg9HnYtr7GvGHfQhTelegram - https://t.me/solodkiyПодписывайтесь на канал «Организованное программирование» в Telegram: https://ttttt.me/orgprog– Список подкаст-платформ (Apple Podcast, Google Podcast, Spotify, Яндекс.Музыка и другие): https://podcast.ru/1734325321– Смотреть в ВК Видео: https://vkvideo.ru/video-224967259_456239247🔹 Telegram-канал Организованного Программирования: https://t.me/orgprog🔹Хекслет Клуб в Telegram https://t.me/HexletClubBot#микросервисы #архитектура #backend #монолит #systemdesign #itподкаст #кириллмокевнин #организованноепрограммирование Монолит или микросервисы?  Что выбрать в 2026  | Алексей Солодкий #76 (00:00) - Введение. Микросервисы — спасение или модная ловушка? (04:40) - Микросервисы тогда и сейчас: что изменилось? (10:43) - Один сервис — ещё не микросервисная архитектура. Разбираем сателлитную модель. (19:20) - Микросервисы 2.0 скоро вернутся? Цикличность хайпа в индустрии. (30:03) - Главный принцип: сервис должен уметь падать безопасно. (38:02) - Бизнес против идеальной архитектуры (44:20) - Пример Amazon: как крупные системы исправляют ошибки оплаты (53:34) - Метрики важнее логов? Почему графики — это правда системы. (01:02:52) - Микросервисы — это пузырь? Возможен ли откат назад (01:14:51) - Почему микросервисы требуют более высокой квалификации (01:23:29) - Стандарты коммуникации: почему каждая компания изобретает своё (01:32:36) - От микросервисов к сателлитной архитектуре (01:41:43) - Заключение: микросервисы — это инструмент, а не религия. ★ Support this podcast ★

Александр Вершилов, разработчик с 15-летним опытом на Haskell. Разбирает, почему в чистом языке возникает проблема IO и как Haskell описывает побочные эффекты через контексты. Говорит о Maybe и связывании вычислений, объясняет do-нотацию и законы монад. Сравнивает подходы с async/await, Result в Rust и обработкой ошибок в других языках.

Сегодня у меня в гостях Рауф Алиев — человек, который варится в поиске уже четверть века. Он начинал с самописного inverted index в начале 2000-х, когда всё приходилось изобретать руками, и дошёл до современных гибридных систем — с векторным поиском, трансформерами и рекомендациями поверх всего этого.Мы обсудили, как вообще устроен полнотекстовый поиск: что такое inverted index на практике, зачем нужен BM25, почему важно учитывать длину документа, что дают proximity и exact match. Отдельно разобрали, почему фасеты — это не совсем «поиск», как работают стемминг и лемматизация, зачем иногда хранить и нормализованный, и оригинальный текст, и почему работа с разными языками — это отдельная инженерная боль.Потом ушли в гибридные модели: как смешиваются ключевые слова, query expansion, синонимы и векторные представления. Поговорили о том, почему векторный поиск лучше понимает смысл, но хуже объясняет свои решения, и как LLM можно использовать не для болтовни в чате, а как инструмент, который превращает человеческий запрос в понятные системе фильтры.Ну и, конечно, обсудили качество. Что такое precision, recall, NDCG на практике, как собрать свой ground truth и как сравнивать конфигурации поиска без мучительных A/B-экспериментов на пользователях. И почему почти всегда, улучшая одну метрику, ты неизбежно просаживаешь другую — и с этим просто приходится жить.Полезные ссылки:https://testmysearch.com/my-books.htmlПодписывайтесь на канал «Организованное программирование» в Telegram: https://ttttt.me/orgprog– Список подкаст-платформ (Apple Podcast, Google Podcast, Spotify, Яндекс.Музыка и другие): https://podcast.ru/1734325321🔹 Telegram-канал Организованного Программирования: https://t.me/orgprog🔹Хекслет Клуб в Telegram https://t.me/HexletClubBot🔹Курсы по программированию — начни учиться уже сегодня: https://ru.hexlet.io/courses#программирование #разработка  #кириллмокевнин  #подкаст  #организованноепрограммирование #поисковыесистемы #invertedindex #векторныйпоискКак работает Search Engine под капотом: ранжирование и релевантность (00:00) - Введение. Поиск сложнее, чем вы думаете - 25 лет опыта за 2 часа (01:07) - От Сфинкса до Elastic: как менялся рынок поисковых систем (06:00) - Теория или практика? Как правильно входить в сложные системы (14:42) - Как SEO и маркетплейсы ломают алгоритмы (19:55) - SEO началось с манипуляций: как PageRank всё изменил (31:12) - Архив за 100 лет и гибридный поиск на практике (44:05) - Гибридный поиск — будущее индустрии (01:01:04) - Транслитерация и языковые ловушки (01:13:53) - Как искать Go или C и не сломать поиск (01:21:54) - LLM как ревизор поисковой системы (01:28:19) - Локальные поисковики против Google (01:32:21) - Китайский без пробелов и другие языковые боли (01:36:45) - Заключение. Поиск — это компромисс между математикой и бизнесом ★ Support this podcast ★

В этом выпуске я заканчиваю цикл разборов книги "Чистый код" Роберта Мартина. Сегодня подробно обсудим одну из самых противоречивых глав,  посвящённую классам, а также найдем ответ на вопрос - "Почему многие привычные критерии «хорошего ООП» плохо работают в реальной разработке"? В этом выпуске я последовательно разбираю, почему ориентация на размеры классов и количество «ответственностей» — это вторичный и часто вводящий в заблуждение критерий, где принцип единой ответственности действительно помогает, а где начинает мешать и подменять мышление, и почему попытки тестировать код через раскрытие внутренних деталей классов почти всегда сигналят о проблемах в дизайне. На конкретных примерах, включая Prime Generator, показываю, как формальные преобразования «по принципам» легко раздувают код, не добавляя ясности, и почему классы сами по себе редко совпадают с реальными границами абстракций, архитектуры и bounded contexts. Отдельно уделил внимание конфликту между ООП-мышлением через классы и подходом через сообщения, состояния и домены, а также объясняю, почему многие аналогии и учебные примеры из Clean Code плохо масштабируются на практику. В конце вас ждут итоги всего цикла: что из книги действительно стоит сохранить, а к чему полезно относиться критически, даже если это давно считается «каноном».Первая часть разбора: https://youtu.be/-tp2bfP36HgВторая часть разбора: https://youtu.be/KK9XK6BtqBMТретья часть разбора: https://youtu.be/bfhUhim0V1YЧетвертая часть разбора: https://youtu.be/DqgAqCpYsbsПодписывайтесь на канал «Организованное программирование» в Telegram: https://ttttt.me/orgprog– Список подкаст-платформ (Apple Podcast, Google Podcast, Spotify, Яндекс.Музыка и другие): https://podcast.ru/1734325321– Смотреть в ВК Видео: https://vkvideo.ru/video-224967259_456239231🔹 Telegram-канал Организованного Программирования: https://t.me/orgprog🔹Хекслет Клуб в Telegram https://t.me/HexletClubBot🔹Курсы по программированию — начни учиться уже сегодня: https://ru.hexlet.io/courses#чистыйкод #программирование #разработка  #чистаяархитектура #кириллмокевнин УпоминанияРазбор второй части чистого кода - https://bugzmanov.github.io/cleancode-critique/clean_code_second_edition_review.htmlПроектирование классов и SRP | Разбор книги Роберта Мартина #5 (00:00) - — Введение. Последний выпуск по "Чистому коду" (01:00) - — Что не так с последней главой? Мнение опытного разработчика (06:36) - — Почему “идеальный программист” — это не миф (13:04) - — Как из одной ответственности вырастает оверинжиниринг (23:49) - — Как SRP сбивает с толку, если применять его вслепую (31:12) - — Миф о сложности: почему “много классов” пугает разработчиков (38:44) - — Объекты против классов: главное заблуждение Java-подхода (47:20) - — Как на опыте рождаются архитектурные решения (55:02) - — Анализ циклов и переменных (01:03:49) - — “Чистый код” как манифест устаревшего ООП (01:10:09) - — Увеличение кода ≠ улучшение архитектуры (01:16:16) - — SRP vs. реальность: почему теория не работает (01:22:30) - — Принципы проектирования не работают без контекста (01:27:00) - — Заключение. Что мы поняли о “Чистом коде”? ★ Support this podcast ★

В этом выпуске  мы поговорили с Антоном Назаровым, создателем сообщества «Осознанная меркантильность», про дебаты как навык и как практику. Разобрали реальные кейсы: удачные, неудачные и спорные.Мы говорили о том, зачем вообще идти в публичные дебаты и какую задачу они решают на самом деле, почему в них важно не переубедить оппонента, а выстроить работу с восприятием аудитории, и как подготовка — или её отсутствие — напрямую влияет на то, «плывёт» человек в разговоре или удерживает позицию. Обсудили, как уточнение терминов и задание рамки разговора меняют динамику дискуссии, какие аргументы чаще всего вызывают агрессию и переходы на личности, где проходит граница между жёсткой позицией и токсичностью, и почему стратегия «всё сложно и все правы» плохо работает в публичном поле.  Отдельно обсудили подготовку к дебатам: работу с тезисами, контраргументами, провокациями и собственными ограничениями, а также почему иногда лучший исход — не идти в дебаты вовсе.Полезные ссылки:Анонсы и эксклюзивы от Антона: https://t.me/m0rtymerr_channelЮтуб Антона:  https://www.youtube.com/@om_nazarov Подписывайтесь на канал «Организованное программирование» в Telegram: https://ttttt.me/orgprog– Список подкаст-платформ (Apple Podcast, Google Podcast, Spotify, Яндекс.Музыка и другие): https://podcast.ru/1734325321– Смотреть в ВК Видео: https://vkvideo.ru/video-224967259_456239229#дебаты #айти #АнтонНазаров #хейт #психология #подкаст #мотивация #саморазвитие #лидерство #критика #мнение #организованноепрограммирование (00:00) - — Введение. Что делает скандальный дебатёр в айтишном подкасте? (01:20) - — Как пережить хейт и не сломаться? Личный опыт Назарова (09:33) - — Коммент, который пробил броню. Бывает ли Назаров уязвим? (17:29) - — «Вами управляет тот, кто вас злит» — правда или мем? (24:01) - — «Все правы» — самый бесполезный подход к контенту (33:55) - — Дебаты с Климовым: снисходительность как стратегия (41:11) - — Как работает манипуляция авторитетом и опытом (50:14) - — Статистика, метафоры, переходы на личности — оружие дебатов (57:05) - — Комбо-приёмы в дискуссии: как выносить без мата (01:01:27) - — IT-Блогеры, разоблачения и мир в баньке. Где граница шоу? (01:09:30) - — Заключение. Как спорить, чтобы вас слушали, а не хейтили ★ Support this podcast ★

Михаил Флёнов, разработчик и автор канала «Програмысли», делится опытом применения паттернов и взглядом на ИИ. Говорит о паттернах как способе мышления и причине их появления. Обсуждает Dependency Injection, границу между простотой и оверинжинирингом и роль паттернов в эпоху LLM. Рассматривает, когда паттерны становятся антипаттернами.

Евгений Лукьянов — архитектор и практик Domain-Driven Design, делится опытом проведения Event Storming-сессий. В ходе беседы он рассказывает о процессах моделирования сложных систем на примере сервиса для контент-креаторов в Telegram. Обсуждаются важные события, воронка активации и критические инварианты. Также затрагиваются проблемы классификации каналов и возможности использования ИИ для автоматизации. Евгений акцентирует внимание на том, как изменение состояния усложняет системы и важности взаимодействия экспертов с разработчиками.

Юниты против интеграционных тестов — вечный спор, который кажется простым только до первого реального проекта. В этом выпуске у нас в гостях Александр Макаровов — core-разработчик PHP-фреймворка Yii. Мы разобрали, почему формальные определения тестов почти не работают в живых системах и где на практике проходит граница между «юнитом», «модулем» и «интеграцией».Мы поговорили о тестировании прикладных веб-приложений и библиотек, сравнили Active Record и Data Mapper, разобрали, когда тесты обязаны ходить в базу, а когда моки — вынужденное зло. Посмотрели реальные репозитории активно развивающихся проектов написанных на Laravel и Rails, фреймворки и коммерческие проекты, и увидели, как на самом деле пишутся тесты в продакшене, а не в книжках. Обсудили фикстуры, транзакции, rollback’и, SQLite in-memory, UUID, миграции, тесты контроллеров, сервисов и джобов.Полезные ссылки:https://t.me/samdark_blogПодписывайтесь на канал «Организованное программирование» в Telegram: https://ttttt.me/orgprog– Список подкаст-платформ (Apple Podcast, Google Podcast, Spotify, Яндекс.Музыка и другие): https://podcast.ru/1734325321– Смотреть в ВК Видео: https://vkvideo.ru/video-224967259_456239227🔹 Telegram-канал Организованного Программирования: https://t.me/orgprog🔹Хекслет Клуб в Telegram https://t.me/HexletClubBot#кириллмокевнин #александрмакаров #интеграционныетесты #программирование #php #backend #разработка #it #подкастДебаты: юнит тесты против интеграционных с Александром Макаровым (00:00) - этом видео: (00:00) - — Добро пожаловать в подкаст: почему третий релиз фреймворка ждали годами — и при чём тут тесты? (02:13) - — О чём сегодня будет спор: юнит-тесты против интеграционных — кто победит? (07:37) - — Юнит-тесты на практике: функция, класс или публичный API (11:14) - — Почему формального определения не существует: юнит-тесты, которые не юнит-тесты (15:05) - — Внутренний интерфейс — трогать или нет: почему тесты не должны лезть в кишки системы (26:18) - — Архитектура vs гигиена: что действительно важно в прикладных проектах (37:15) - — Рефакторинг без боли: какие тесты действительно помогают менять код (47:53) - — Работа с базой данных: транзакции, откаты и скорость тестов (59:49) - — Плюсы и минусы высокоуровневых тестов (01:08:11) - — Open-source vs коммерция: почему одинаковые подходы не работают (01:25:45) - — Все типы тестов в реальном проекте (01:42:55) - — Docker и файловая система: неочевидные проблемы масштабирования (01:54:10) - — Сила декларативного подхода: почему CI/CD — идеальная среда для AI (02:01:20) - — Заключение: почему истина всегда где-то посередине ★ Support this podcast ★