Мы в Satori тоже регулярно сталкиваемся с вендорами ПО. Раньше я как-то не особо обращал на это внимание… но теперь я просто в восхищении от того, как изящно устроен этот рынок. Узнал потрясающие вещи:

- Оказывается, API можно смело поставлять без документации — вы же умные, сами разберетесь.
- При этом часть API будет отвечать Not Implemented
- Можно брать деньги за доработки, а потом бодро сообщать: «Ну… не получилось».
- На вопрос «почему столько багов и есть ли у вас тесты?» присылать набор юнит-тестов, сгенерированный вчера ИИ, причём таких, что они не проверяют вообще ничего.
- Спокойно тестировать прямо на проде клиента — идеально же, всё под рукой.
- Игнорировать вопросы даже в платной техпододдержке — бережём энергию.
- На срочные запросы отвечать: «Единственный человек, который в теме, у нас сейчас в отпуске».
- Требовать оплату за работы, которых в природе не существовало.
- На просьбу о функциональности говорить: «Этого нет в нашем беклоге и никогда не появится».
- Продавать «коробочное решение», которое по факту — франкенштейн из копролита, костыля и поделия джуна после курсов.
- Обвинять заказчика, в том что он нормально задачу не ставит и не проверяет
- И главное, абсолютный шедевр: подсадить клиента на «бесплатное решение», а потом элегантно выкручивать ему руки за доработки.

Вот это я понимаю, бизнес-модель!

DIY для банка: выбираем базу данных, когда стартап нас отшил

В предыдущей серии я рассказывал, как TigerBeetle — стартап нашей мечты — отправил нас во френдзону. Пришлось засучить рукава и делать «сердце» банка самим.

Но на чем писать? Чтобы не было мучительно больно за бесцельно прожитые спринты, мы сформулировали требования.

Задача:

- 1000 TPS (транзакций в секунду) на рандомных аккаунтах.
- 100 TPS на одного «жирного» клиента.

С первым пунктом всё понятно: если руки растут из плеч, любая современная БД это вывезет. А вот второй пункт — это боль. Нужно заблокировать аккаунт, посчитать баланс, записать проводку и разблокировать. Арифметика беспощадна: 1 секунда / 100 транзакций = 10 мс на всё про всё. Тут уже на Python не попишешь, тут думать надо.

В кастинг на роль «сердца» попали четыре кандидата:

1. Postgres (Классика)
Старый добрый слон. Чтобы уложиться в 10 мс, всю логику придется зашивать в хранимки (Stored Procedures). Гонять данные туда-сюда между приложением и БД — непозволительная роскошь. Сомнения: Наша текущая система на MySQL выдает жалкие 7 TPS. Вендор клянется мамой, что это предел физики. Мы, конечно, умнее, но сможем ли мы быть умнее на порядок? Вопрос открытый.

2. Redis + Postgres (Безумный Макс)
Идея для смелых: ставим Redis перед Постгресом. — «Но это же просто кэш!» — кричат пуристы. — «Подержите мое пиво», — отвечаем мы.

Почему это круто:

- Single-threaded: Редис однопоточный. Никаких гонок (race conditions). Атомарность из коробки.

- Lua noscripts: Логику можно исполнять прямо внутри памяти. Быстро, дерзко.

- Надежность: У Редиса есть стримы. Можно реализовать Transaction Outbox паттерн без танцев с бубном, Kafka и Debezium. Данные льются в Postgres в фоне.

- Персистенс: Да, вся база должна лезть в RAM. Но Редис умеет сбрасывать данные на диск и реплицировать на слейвы. Если настроить прямыми руками — надежно, как швейцарские часы.

3. TigerBeetle (Бывшая)
Те самые ребята, которые нас отшили. Заявляют 1 000 000 TPS. Даже на один аккаунт. Звучит как сказка, но проверить надо. Вдруг врут? А если не врут — будем кусать локти (или снова проситься к ним).

4. Google Spanner (Швейцарский нож)
Самый загадочный зверь. Спрашиваешь у Гугла, что такое Spanner, и тебе отвечают: «ЭТО ВСЁ».
Хочешь SQL? Spanner.

Хочешь Key-Value? Spanner.

Графы? Spanner.

AI? Разумеется, Spanner! Там скоро можно будет писать запросы в духе: «AI, проверь, хватит ли у юзера 123 денег на пиво, и если да — переведи».
На презентации меня сдержало только хорошее воспитание, чтобы не спросить: «А блокчейн вы туда еще не впихнули?». Похоже, это единственное, чего там нет.

Проблема: Это распределенная БД. Она сама решает, где хранить данные. Скорее всего, она раскидает счета по разным нодам, и каждый перевод превратится в multi-node transaction. А это медленно. Но Гугл так настойчиво поил нас кофе и водил по виски-барам, что мы решили дать Спаннеру шанс. Из вежливости.

------

Результаты эпичной битвы и реальные цифры нагрузочного тестирования — в следующем посте.

А пока вангуем в комментариях. В каком порядке тулзы пришли к финишу (от лучшей производительности к худшей). И какую технологию выбрали бы лично вы?

Кто будет ближе всех — тот настоящий HighLoad архитектор.

Финал: Битва баз данных. Кто стал сердцем банка?
[В прошлых сериях]: нас отшил дерзкий стартап, мы обиделись и пошли пилить своё решение. Задача была простая, как кирпич: найти хранилище, которое выдержит наши амбиции. 🎯 Цель: — 100 TPS (транзакций в секунду) на один аккаунт (с блокировками). — 1000 TPS на рандомные аккаунты.

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


1. Postgres (Старый конь борозды не портит)
Взяли его чисто как baseline, чтобы было с чем сравнивать. Вся логика строго на хранимках (Stored Procedures), один поход из приложения в базу.

Результат:
Один аккаунт: 1 300 TPS (В 13 раз больше требуемого! Мы слегка присели).
Много аккаунтов: 9 000 TPS.

Внезапно «скучный» SQL показал, что списывать его со счетов рановато.


2. Redis + Postgres (Форсаж)
Схема: Редис считает математику в памяти, а потом стримами (Streams) скидывает данные в Постгрес на вечное хранение.

Результат:
Один аккаунт: 23 000 TPS.
Много аккаунтов: 23 000 TPS.

Ему вообще плевать. Редис однопоточный, ему все равно хоть один аккаунт, хоть много. Скорость света.


3. TigerBeetle (Тот самый стартап)

Результат:
Один аккаунт: 27 000 TPS.
Много аккаунтов: 77 000 TPS.

Обещанного миллиона мы не увидели, но цифры всё равно мощные. Правда, прямо посреди теста мы словили эксепшн:

Whoops, there is a bug in SDK…

Мелочь, а неприятно. Представили, как ловим этот «Whoops» в продакшене в «Черную пятницу», и перекрестились.


4. Google Spanner (Боль и унижение)
Напомню, Гугл продавал нам это как «Решение Всех Проблем Человечества».

Результат:
Один аккаунт: 78 TPS. (Нет, я не забыл букву «K». Просто 78).
Много аккаунтов: 870 TPS. (Тоже просто 870).

Мы протерли глаза. Перезагрузили серверы. Цифры не изменились. Звоним в Гугл: «Ребята, что за фигня? Где обещанная магия?»

Нам вежливо посочувствовали и выдали гениальные советы:
- «А вы поставьте перед Спаннером Redis». (Спасибо, Кэп! А Спаннер тогда зачем?).
- Скинули статью на Medium: «Какие костыли прикрутить, чтобы базы данных хоть как-то работало с hot accounts».
- Рассказали вдохновляющую историю, как один банк реализовал на Спаннере... фичу кэшбека. (Кэшбека, Карл! Не леджера).

Когда мы наконец прорвались через продажников к суровым технарям, те вздохнули и признались: «Ну да, сотню TPS выжмете, больше — вряд ли. Архитектура такая».

Занавес.

------

Итоговое решение
Мы выбрали Postgres.

Почему:
- Запас прочности: Он выдал 1300 TPS на один аккаунт при требовании в 100. Этого нам хватит на годы.
- Надежность: Это скучная, предсказуемая технология. Никаких «Whoops» в SDK.
- Архитектура: Мы спроектировали систему так, чтобы оставить перед Постгресом «Redis-shaped hole» (дырку в форме Редиса).
- Если (или когда) мы вырастем до космических масштабов, мы просто вставим туда Redis, как деталь пазла. А пока — зачем платить сложностью за то, что старый добрый SQL делает бесплатно?

А теперь предлагаю погуглить "Spanners British slang". В общем, хорошую штуку Спаннером не назовут

Как я предлагал вернуть Монолит и сэкономить миллионы.

Лично мне вариант с Redis понравился больше всего. Быстро, дерзко, молодежно. Но была одна проблема: Redis работает идеально ровно до тех пор, пока данные влезают в оперативку. Как только память заканчивается — карета превращается в тыкву. А постоянное переливание данных в Postgres через стримы выглядело как надежный, но все-таки костыль.

И тут меня осенило. Я пришел к нашему Principal Engineer с Гениальным Планом™.

— Слушай, — говорю я с максимально серьезным лицом. — Я тут порылся в закромах Google Cloud. У них есть машина с 5 ТБ оперативной памяти. — И? — Стоит всего $10k в месяц. Я прикинул: туда влезут все наши данные года за три. Вообще всё. И никаких костылей с переливкой.

Диалог вышел коротким: PE:

— А через 3 года, я полагаю, ты уволишься? Я: — Зачем же? Через 3 года у Гугла появится инстанс на 7 ТБ. Просто переедем на него за ночь.

------
Самое смешное в этой машине — это процессор. Там 200+ ядер. А наш любимый Redis, как мы помним, однопоточный. Ему нужно 1.5 ядра:

1 ядро — крутить транзакции.

0.5 ядра — на IO и «на чай» операционной системе.

Остальные 198.5 ядер будут простаивать. Хотя, почему простаивать? Можно запустить майнинг Биткоина. Глядишь, и стоимость аренды отобьем, и в финтех-отчетах покажем «альтернативные источники дохода».
------

В теории, на одну такую машину влезет весь наш немаленький банк. Целиком. Если перестать играть в микросервисы, Kubernetes и распределенные системы, а просто собрать честный, старый добрый Монолит.

Ну ладно, для отказоустойчивости возьмем две такие машины. Master и Slave. Всё равно экономия на инфраструктуре выйдет раз в 10. Никаких сетевых задержек, никаких проблем с согласованностью, деплой простым копированием бинарника.

Звучит как полный бред сумасшедшего. Или всё-таки нет?

#Юмор

Может показаться, что выход — просто брать опенсорс вместо всех этих вендоров. Но и здесь хватает юридических и организационных рисков. Одно дело — суперпопулярный PostgreSQL, другое — какой-нибудь нишевый фреймворк, который завтра может тихо умереть, а специалистов по ним больше не существует. Да и сами опенсорс-проекты умеют переобуваться.

Относительно свежий пример — MinIO. На главной странице теперь честно пишут:

This project is currently under maintenance and is not accepting new changes. 
For enterprise support and actively maintained versions, please see MinIO AIStor.

А ещё раньше они фактически убрали консоль администрирования (если я правильно понял), объяснив:

Honestly, it is hard to duplicate this work for the community branch…

Без обид — жестокие улицы Сан-Франциско каждый день требуют дозы Enterprise-лицензии. Но с опенсорсом хотя бы остаётся код: можно форкнуть, допилить, поддерживать сами или в сообществе.

С коммерческим продуктом всё жестче: если компания закрылась — код ушёл вместе с ней в закат над Golden Gate.

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

Как сделать систему непригодной к использованию и назвать это гибкостью

Еще разок про универсальщину. Попался прямо таки каноничный пример как делать не нужно.

Итак, есть вендор. В их системе весомая часть действий — это документ (так исторически сложилось).
Не важно, что происходит: создаём заявку, выполняем операцию, меняем состояние — всегда создаётся документ.

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

Примерно вот так:

POST /documents
{
  "type": "X",
  "field1": "...",
  "field2": "...",
  "field3": "а может и не нужно"
}

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

Ну и вишенка на торте — у документа может быть свой набор состояний или действий. Как результат — целый кабинет аналитиков и разработчиков пытается расшифровать что происходит и как с этим жить.

Вывод простой: даже если внутри системы всё построено на документах — не делайте универсальные интерфейсы. Типизированные контракты и явные модели почти всегда выигрывают у гибкости ради гибкости.

Я проехал 1000 км в автодоме и вынужден поделиться этим экспериенсом с вами

Сегодня никакой душноты про DDD. Поделюсь с вами пережитым в отпуске!

Решил, что простого отпуска мне мало, и вывез жену с двумя детьми в Тасманию. Чтобы жизнь медом не казалась, мы арендовали автодом. Неделю мы в нем спали, ели и, простите, производили удобрения.

Ощущения за рулем За эту неделю я превратился в сурового дальнобойщика Джо. Наш дом на колесах размером с ПАЗик (3.5 метра в высоту!), а дороги в Тасмании строили для хоббитов. Едешь, потеешь: слева 15 см до обрыва, справа 15 см до встречки. А навстречу летит такой же перепуганный Джо, в глазах которого читается молитва и полное непонимание габаритов.

Самое смешное, что для управления этой махиной годятся наши обычные права категории B. Видимо, считается, что если ты смог сдать на «Ладе», то и сарай на колесах укротишь.

Акустический комфорт (его нет) Автодом — это симфония разрушения. Ощущение, что везешь бабушку на дачу вместе со всем содержимым ее сарая. Где-то сзади ритмично лязгает эмалированное ведро, над ухом скрипит кровать, периодически что-то с грохотом падает.

Езда по городам — отдельный тест на стрессоустойчивость. Видел австралийца, который к такому же автодому прицепил сзади легковушку на жесткой сцепке. Правда, они застряли на подъеме. Не уверен, что уровень стресса у них снизился, но попытка засчитана.

Есть, конечно, вариант с прицепом-трейлером. Едешь в джипе, кайфуешь, а дом болтается сзади. Но туда нельзя посадить детей. Хотя... если у вас есть парочка запасных, то почему бы и нет?

🔜 В следующем посте расскажу, каково это — жить в коробке вчетвером и не убить друг друга.

Пост №2. Быт, дети и алкоголизм как стратегия
🏠 Выживание в автодоме: инструкция по применению

Продолжаю рассказ про наш тасманский вояж. Многие думают, что автодом — это про экономию. Ха! Мы почти не сэкономили, зато познали дзен бытовой лени.

Главный плюс Вам не нужно каждый день играть в тетрис с чемоданами. Просто сгребаешь в кучу всё, что может кататься по салону и убить кого-то на повороте, загоняешь детей внутрь — и погнали.

Личное пространство Оказывается, 5-6 метров дистанции между родителями и детьми творят чудеса. Мы с женой в кабине — приличные люди, обсуждаем высокие материи. Дети сзади валяются на кровати (да, так ехать кайфово, пока не начнешь тормозить). Идиллия.

Планирование? Не слышали Project Management остался на работе. Наш метод — «слабоумие и отвага». Был только список мест, а где ночевать — решали по факту. Перспектива остаться ночью в поле не пугает, когда твой дом едет с тобой. А вот стоянки платные. Просто ровная площадка — $12. Хочешь воды, электричества и слить... накопленное? Гони $15–30. Бесплатно стоять нельзя, дальнобойщик Джо должен платить.

Комфорт На удивление, это полноценный дом. Две кровати, душ, туалет, холодильник. Жена даже умудрилась пожарить настоящий стейк на микро-плите! Мы пришли к выводу, что могли бы так прожить еще пару недель. Чилить в кемпингах, обсуждать артрит с австралийскими пенсионерами и деградировать.

🍷 Лайфхак для алкоголиков-эстетов: Некоторые винодельни Тасмании разрешают кемперам ночевать на их территории. Тур от винодельни к винокурне с ночевкой на месте дегустации — звучит как идеальный план на старость.

Пост №3. Сухие цифры для Скруджей Макдаков
💰 Сколько стоит стать улиткой?

Подбиваем бабки нашего эксперимента с автодомом в Тасмании. Если вы думали, что это дешевый способ путешествовать — у меня для вас плохие новости.

Итого за неделю (цены в USD): 📉 Аренда дома: $1000. 📉 Стоянки (чтобы поспать легально): $200. 📉 Топливо: $200 (я ожидал, что этот сарай жрет больше, приятный сюрприз). 📉 Еда, рестораны, вино (много вина) и кофе: $1000.

Итого: ~$2400 за неделю на четверых.

Вердикт: Смысл брать дом, а не отель + авто?

Не собираешь чемоданы.

Дети далеко от водителя.

Можно проснуться с видом на виноградник и сразу начать... дегустировать.

Повторил бы я? Да. Но беруши купил бы заранее.

Реальность vs Ожидания: что мы узнали из общения с вами

За последние недели мы провели плотные сеанс обратной связи по курсу "Разработка без боли и сожалений". Нам было важно поговорить с двумя разными группами:
- С теми, кто только планирует обучение и ищет точки роста.
- С выпускниками, кто уже пережил курс и успешно внедрил практики в работу своих команд.

Это был не просто разговор, а глубокий разбор полетов. Мы узнали:
- Что реально работает в бою, а что — не сработало.
- Где ожидания совпали с реальностью, а где были сюрпризы.
- С какими вызовами вы сталкиваетесь прямо сейчас.

Этот срез реальности помог нам скорректировать фокус, чтобы разбирать не сухую теорию, а живые, актуальные кейсы.

🚀 Что дальше? Следующий поток стартует в феврале. Мы уже обновляем программу с учетом полученных инсайтов. Главная новинка: добавим блок про то, как заставить ИИ реально помогать, а не генерировать рандомные баги. Спойлер: в связке с DDD получается настоящая ИМБА.

Если вы рассматриваете участие — мы открыли предзапись. Это ни к чему не обязывает, но вы точно не пропустите старт и получите лучшие условия.

👉 [Ссылка на предзапись]

Спасибо всем, кто поделился опытом и помог сделать продукт лучше!

Я тут неожиданно для себя обнаружил, что пора обновить роутер.
Не потому что старый плохо работал — нет, он ещё бодр, как Java 8 в проде.
А потому что пришёл Wi-Fi 7 и Wi-Fi 6E, а вместе с ними — священный диапазон 6 GHz, который пока не засран соседями. Надо брать, пока можно.

Скорости, конечно, обещают чудовищные.
Я ещё помню времена, когда от одного провода зависело — будет у тебя 10 или 100 Mbps.
А теперь вот это всё, без тени стыда:
11520 Mbps (6 GHz, EHT320)
+ 5760 Mbps (5 GHz, EHT240)
+ 1376 Mbps (2.4 GHz, EHT40)

Да, мне тоже не совсем понятно где и когда я буду это использовать,
но звучит убедительно, а значит — надо.

Самый мучительный процесс после покупки роутера — выбор имени Wi-Fi сети.
Тут важна архитектура, доменная модель и, конечно, чувство юмора.

Мы с ChatGPT, как большие фанаты Star Wars, решили проблему за вас.
Теперь мучаться придётся только один раз — при выборе роутера.

Готовые имена сетей:
• Obi-WAN Kenobi
• The LANdalorian
• Rogue WAN
• Wi-Fi Awakens
• Return of the Ping
• A New Hop
• These Are Not the Droids
• R2-D2.4GHz
• The Force Is Strong
• You Underestimate My Bandwidth
• May the Wi-Fi Be With You
• LAN Solo

Роутер в итоге взял TP-Link EB810v, за 170USD с рук. Цена нового около 500USD (очень люблю когда хорошие роутеры идут в подписке у провайдера. Их можно потом найти по бросовым ценам).
Если кому интересно — спрашивайте.
Если не интересно — всё равно назовите сеть красиво.

Бизнес-схема года: Как мне предложили ничего не делать и получать сингапурскую зарплату

Обычно мой инбокс забит однотипными письмами от HR про "молодую динамичную команду" и "печеньки в офисе", но сегодня матрица дала сбой и подкинула мне кое-что поинтереснее

✍️ Пишет некий Thai Can (звучит как девиз, но это имя). Программист из Вьетнама, JS/C# сеньор-помидор. Суть стартапа: Вьетнам — бедный, Сингапур — богатый. Я нанимаю его "в черную", он кодит за меня за свои вьетнамские копейки, а я получаю свою сингапурскую котлету и «сосредотачиваюсь на более важных вещах». Ну и конечно, никто ничего не узнает. План надежный, как швейцарские часы.

Это письмо заставило меня задуматься (нет, не о том, чтобы согласиться), а о том, в какой параллельной вселенной это вообще могло бы сработать.

Почему в Jago Bank этот «аттракцион невиданной щедрости» обречен:

- Разработка — это не только стучать по клавишам. У нас (особенно на позициях Senior+) кодинг занимает дай бог 40% времени. Остальное — это бесконечные попытки понять, кому эта фича нужна, что конкретно там нужно и как не уронить прод. Если я найму Тая, мне придется работать переводчиком с «бизнесового» на «технический» фул-тайм.

- Слабоумие и отвага. Дать левому чуваку из интернета доступы к банковской инфрастуктуре? Звучит как начало отличной истории для прокурора. А если код утечет — IP будет мой, логин мой, а тюрьма — общая (хотя нет, только моя).

- Синдром Staff Engineer. На моем уровне всем плевать, сколько кода я написал. Если я вдруг начну выдавать x3 объема, начальство даже бровью не поведет. А вот если качество кода просядет (а оно просядет, ведь Тай не в контексте наших костылей), коллеги меня сожрут.

Где этот бизнес-план мог бы взлететь?
✅ В галерах, где аналитик пишет ТЗ, закрывшись в бункере, потом выбегает, швыряет его в разрабов и баррикадирует дверь, пока не побили вопросами.
✅ На позиции мидла-формошлепа, где KPI — это количество закрытых тикетов.
✅ Если вы адепт секты Over-employment и любите жить на адреналине.

И финальный гвоздь: Этот предприимчивый вьетнамец хочет забрать у меня самое приятное — Творение (коддинг), и великодушно оставить мне унылые митинги, согласования и политику?! Ха! Ну уж нет. Страдать на созвонах — это работа, а писать код я и сам люблю.

👇 Что думаете? Сработало бы такое в вашей компании или СБ вычислит через 5 минут? И признавайтесь, есть знакомые, кто успешно "делегировал" себя?

Устали от поедания салатов, поэтому взяли и смоделировали с Кириллом Мокевниным целую систему. Приятного просмотра!
https://www.youtube.com/watch?v=gyaDwoDvsWY

Отмазка «это долго» умерла. Да здравствует «мы просто не умеем»

(Все нижесказанное конечно же ИМХО, на истину не претендуем)

Последние несколько недель плотно сидел в теме ИИ в разработке. Готовлю ролик (выйдет на днях), но если коротко — у меня для вас две новости.

Хорошая: ИИ пока никого не заменяет.
Плохая: Это вопрос времени. Потребность в таком количестве белковых «рабочих рук» неизбежно рухнет. И хотя полной картины нет вообще ни у кого (хотя я видел очень много крутых демок), направление движения более чем понятно.

Главные мысли за это время:

🔻 Масштабирование хаоса — ИИ не магия и не серебряная пуля. Это мощный ускоритель. Если у вас в проекте архитектура из соплей и палок, а стратегия — накидать лапши и героически её поддерживать, поздравляю: ИИ поможет вам нагенерировать эту лапшу в 10 раз быстрее. Вы утонете в собственном легаси быстрее чем когда либо.

🔻 Смерть отговорки «это долго» Раньше можно было ныть, что писать тесты — это дорого и долго. Теперь эта отмазка мертва. Код генерируется пулеметной очередью, и без автотестов отдел ручного QA захлебнется в слезах уже через неделю. Теперь придется признать честно: мы не пишем тесты не потому что долго, а потому что не умеем.

🔻 Конец эпохи «я просто кодер» Позиция «я пришел писать код, не грузите меня бизнесом и требованиями» стремительно обесценивается. Сам по себе код становится дешевым сырьем. Мы еще года полтора назад в одном из роликов говорили (и нас в комментах за это закидали помидорами), что профессия делится на два лагеря:
⁃ Инженеры: Понимают процесс целиком — от требований до продакшена.
⁃ Все остальные: Скоро выяснят, что знание синтаксиса языка и нюансов по склейке кривых библиотек между собой больше не тянет на полноценную зарплату.

🔻 Вендоры напряглись Продавцы дорогих коробочных решений, которые работают кое-как, а их доработка стоит миллионы (да и вообще у нас в беклоге такого нет), должны начинать нервничать. Бизнес-логику теперь проще и дешевле отреверсить и собрать свое, чем годами платить за чужое раздутое ПО.

Итого: Сказки про то, что можно ничего не понимать и ИИ всё сделает сам — для бедных. Выигрывают те, у кого и без ИИ был порядок в процессах, архитектуре, дизайне. А остальные просто быстрее добегут до тупика. Если хотите победить — учитесь понимать систему целиком, иначе останетесь за бортом истории вместе с верстальщиками на таблицах.

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

Прошло несколько лет и благодаря DDD, чистой архитектуре, собственному небольшому фреймворку, ИИ-агентам и большому количеству выстраданных правил, мы за вечер делаем больше, чем раньше за неделю, и при этом получаем не лапшу, а поддерживаемый и предсказуемый код.

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

Наш курс — про разработку как систему, от требований и моделирования до кода и автотестов. В этом потоке мы покажем, как ИИ вписывается в процесс и как он реально помогает, но суть разработки за вас он не выучит — её нужно понимать полностью.

Вы узнаете:
- Что писать в требованиях, чтобы команда понимала задачу с первого раза;
- Какие инструменты делают разработку удобной;
- Как измерять архитектуру цифрами, а не на глазок и поддерживать ее в чистоте;
- Как строить модель предметной области через Event Storming, чтобы масштаб катастрофы был понятен сразу;
- Как писать тесты, которые помогают в разработке, а не мешают;
- И мы даже разберём коммерческое приложение, построенное по принципам DDD и чистой архитектуры, чтобы вы увидели всё вживую, а не на хелловорлде;
- Какие практики являются обязательными в лучших домах Парижу у лидеров отрасли;
- Поноем про говнокод на работе и обсудим что с ним делать;

Суммарно мы проведём с вами более 30 часов практических занятий, не считая лекций в записи и домашек, и за это время сначала сломаем привычное кодерское мировоззрение, а затем соберём его заново — уже в виде инженерного подхода, который реально работает в продакшене.

Если вы хотите перестать «просто писать код», начать реально управлять процессом разработки и чувствовать себя гораздо увереннее на всё более нестабильном рынке труда, мы запускаем новый поток курса, который стартует в феврале.

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

Свободных мест осталось всего 5.
Анкета предзаписи — по ссылке.

А вот и обещаный видосик, если кто еще не видел. Приятного просмотра!
YouTube | ВК

А еще есть сомневающиеся в возможностях llm :)


10 минут моего времени
35k строк кода на бэке
40k строк кода на фронте

Сказка… а теперь берем эту сказку и SAST’ом по ней

• XSS через SVG
• allow_methods=["*"] и allow_headers=["*"]
• Отсутствие rate limiting
• Отсутствие лимитов на размер данных
• Race conditions в глобальном состоянии
• denoscription может содержать небезопасные данные
• нет логирования действий пользователей

Ну и понятное дело NFR’ы неизвестны, нужно под нагрузкой подержать, помасштабировать и… что если не держит продукт нагрузку? Нередко строчки кода тут не помогут и Claude тоже в вопросах архитектуры пока не может помочь (дело времени, но пока не может).

Поэтому я и говорю – архитектура/дизайн вышли на первый план, ну иначе я не знаю как получить рабочее решение, чтобы оно NFR’ам удовлетворяло.

Вот, кстати, отличная иллюстрация наших разговоров.
Серёжа Баранов за короткое время запилил вполне немаленькую тулзу — десятки тысяч строк кода, всё выглядит рабочим. Но если копнуть внутрь, сразу вылезают вопросы по безопасности, ограничениям, NFR и архитектуре в целом. И опять выясняется: нужно понимать весь процесс разработки целиком, а парой тысяч строк кода эти проблемы не дописываются. LLM сильно ускоряют разработку, но «работает» ≠ «готово к продакшену».

Просматривая комментарии к видео, бросились в глаза фразы вида

«Да я тут целый магазин сгенерил, че ты мне тут свистишь, всё работает»

Давайте-ка вспомним, чем отличается промышленная разработка энтерпрайз-монстров от MVP (кстати, я подчеркнул, что речь именно про промышленную разработку — но, похоже, это пролетело мимо ушей):

1. Энтерпрайз — это всегда легаси. Легаси не значит плохо, это значит, что вы имеете дело с кодом, который работает уже десятки лет. Никакого контекста не хватит, чтобы впихнуть кодовую базу.

2. Есть вопросы безопасности — куда и что отправляет этот ваш модный Курсор?

3. В таких проектах есть процесс работы с продуктом: планирование, ревью, тестирование, деплой. Написание кода — лишь маленькая часть, и она далеко не самая длительная.

4. Помимо функционала есть требования к качеству ПО: стабильность, поддерживаемость, безопасность. Любое изменение — это риск. Сносить всё и перегенерить заново нельзя, иначе придётся проходить весь процесс заново.

5. Как насчет мониторинга и поддержки? MVP точно предоставляет все метрики, настраивает алеры и т.д.?

6. Технический долг — отдельная тема, накапливается очень быстро, и маленькие изменения через полгода могут остановить всю команду. То на что можно забить в MVP будет неприемлимо в промышленной разработке (хотя кого я обманываю, просто на работе подольше посидите, кек).

7. Обратная совместимость — еще одна причина почему нельзя все снести и построить заново.

8. Экономическая сторона — сколько стоят токены, запросы к ИИ, ресурсы? Какие вычислительные мощности нужны, кто их обслуживает? За чей счет банкет?

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

В связи с этим нам интересно: знаете ли вы большие вайбкод-проекты, которые лежат в общем доступе? Может, вы сами участвуете в таких проектах? Напишите в комментариях — если найдём что-то интересное, можно будет сделать разбор