Видео о том, что нас беспокоит в нашей уютной айтишечке. Если ещё не видели — самое время. Приятного просмотра!

YouTube | ВК

В комментах к моему видосу — про то, что сколько БД и фреймворков ни меняй, всё равно получается неподдерживаемое говно — несколько человек решили возразить: «ты че, пёс, я — инноватор».

Так вот, давайте откроем введение к книге Вона Вернона по DDD. Он пишет об Эрике Эвансе:

Эрик Эванс посвятил своей первой выдающейся работе по DDD пять лет. Без принципов, выросших из языка Smalltalk и шаблонов, а также уточненных самим Эриком Эвансом, многие разработчики вынуждены были бы поставлять плохое программное обеспечение. К сожалению, эта проблема является более распространенной, чем хотелось бы. Как рассказывает Эрик, плохое качество разработки программного обеспечения и безынициативность апатичных команд разработчиков программного обеспечения почти подвели его к решению уйти из программной инженерии навсегда. Мы должны горячо поблагодарить Эрика за то, что он сосредоточил свою энергию на образовании, а не на новой карьере.

20+ лет прошло, а ощущение — будто всё на том же месте.
Может, за следующие 20 хотя бы тесты научимся писать.
Хотя теперь апатично разрабатывать стало даже проще — спасибо ИИ.

Суббота, а значит самое время посмотреть еще одно видео про Value Objects. Теперь говорим про коллекции, как их можно представить в виде объектов-значний и зачем это нужно. Приятного просмотра!

YouTube | ВК

К 2030 году команды разработки будут меньше, но их станет существенно больше.

Такой прогноз даёт Gartner, и лично мне этот тренд кажется очень здоровым для отрасли.

📊 По данным Gartner:
• 80% компаний сократят большие инженерные команды в пользу малых, AI-усиленных команд.
• 40% корпоративных приложений будут разрабатываться на AI-native платформах (в сравнении с 2% в 2025!) — почти 20-кратный рост.

То есть речь не о сокращениях ради сокращений, а о переходе к другой модели: не «одна гигантская команда», а много маленьких автономных команд + ИИ-агенты.

⸻

Почему это хорошо для нас — разработчиков?

• Меньше людей → меньше коммуникационных накладных расходов.
Меньше митингов, меньше бюрократии, больше фокуса на деле.

• Парное программирование станет нормой, но напарником будет ИИ.
Он всегда на связи, не выгорает и не «надоедает».

• Рутина уходит машинами.
Генерация REST-контроллеров, CRUD-логики, конфигураций инфраструктуры — автоматизируется.

• Фокус смещается на архитектуру и доменную экспертизу.
Самое интересное остаётся у людей.

• Больше ценности — больше компенсация.
Когда твой вклад становится ближе к продукту и бизнесу, растёт и стоимость работы.

⸻

Иначе говоря:
ИИ — это не “замена”, а “усилитель”, способный освободить нас от низкоуровневой рутины и вернуть разработку к инженерии.

Как вам такой поворот событий?
Верите, что tiny teams — это будущее? Или есть риски, которые вас тревожат? 👇

Gartner прогнозирует, что будущее принадлежит доменно-специализированным ИИ-моделям.

Не уверен, что это прям так и будет. В конце концов, ChatGPT — это Generative Pre-Trained Transformer: его изначальная идея была — «научить читать, а потом дообучить под задачу». Но по факту он уже «из коробки» оказался достаточно умным, чтобы решать кучу задач без всякого доп. обучения.

Так или иначе, уже сегодня ИИ стал крайне полезным для изучения предметной области и реально заменяет аналитика процентов на 80.

⸻

Как мы используем ИИ в команде

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

Самым эффективным способом обучения оказалось… просто поговорить об этом с чатом.
Объяснить на примерах, попросить отразить проводки в бухгалтерской книге, задать уточняющие вопросы, попросить «разложить на пальцах», что такое Debit для Liabilities и почему так.

⸻

Процесс онбординга теперь выглядит иначе

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

Результат?
Количество странных коммитов и попыток «заложить архитектуру на случай, если вдруг появится что-то кроме Debit и Credit» сократилось практически до нуля.

⸻

Вывод

Изучайте предметную область вместе с ChatGPT.

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

Когда игрался с Primitive Obsession и проиграл.

P.S.: чтобы такой фигни не было, используй Value Object

Отвечаем на самый волнующий вопрос при запуске новых проектов, MVP и стартапов. Приятного просмтра!

YouTube | ВК

Хочется почитать какую-нибудь стоящую книгу по разработке или около-разработческой тематике.
Что можете порекомендовать из относительно новых?

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

Youtube | ВК

Хотите кек? Попалась недавно система, где первичный ключ — это персональные данные (не буду говорить какие, потому что вендор себя опознает). Ну а чё, гениально же! Зато сразу понятно, кто есть кто — никакой анонимности, никаких лишних UUID. Правда, теперь все интеграции должны соблюдать законы о ПДн, проходить аудиты и жить по регламентам. Зато — очень удобно. А главное — персональные данные ведь никогда не меняются, да?

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

YouTube | ВК

Недавно наткнулся на codecrafters.io — прикольный сервис, где можно с нуля реализовать всякие штуки вроде Redis, Git, SQLite и прочее непотребство.

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

Каждое задание там — это разбор под капотом: сетевые протоколы, файловые форматы, системы хранения, парсеры и всё то, что обычно «просто работает».

Есть бесплатный тариф, так что можно попробовать без вложений.
Мы сами пока не юзали, но выглядит интересно

Я юзал с целью "освоить незнакомый язык на реальном проекте", мне понравилось. Из прикольного - все проекты делаются по baby steps (например, Redis начинается с задания "сделайте TCP-сервер, который отвечает PONG на PING на нужном порте), это сильно помогает постепенно въехать в новую технологию. Из не очень прикольного, но по-своему полезного - в заданиях обычно пишут, что делает, но практически не дают пояснений, как; если непонятно, приходится лезть в документацию, в другие решения, которые там же можно посмотреть, или спрашивать у ChatGPT). Бесплатно дают доступ к одному проекту, который меняется каждый месяц, плюс, когда они добавляют новый проект, у него есть период бета-тестирования, когда он тоже бесплатен.

Когда-то давно мне приспичило разобраться как работает Linux. Нашёл Linux From Scratch — проект, где ты буквально собираешь систему с нуля. Но это упоротый вариант.

В итоге я остановился на Arch Linux — почти как Gentoo, только без бесконечной пересборки мира.
Поднимал сети вручную, вкорячивал модули ядра, правил grub.cfg, шаманил с udev и драйверами.
Естественно, сейчас я уже всё это забыл и зову админа чтобы подключить сетевой кабель. Но тогда, когда я занимался прошивками и разрабатывал под Linux, это дало мне дикий буст к пониманию того, как система устроена изнутри. И вот это как раз пет-проект класса «Минимализм» — когда ты воссоздаёшь базовый слой, чтобы прочувствовать механику. Но есть опасность — после таких экспериментов у вас может прорасти свитер

🔧 Немного закулисья нашей разработки

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

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

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

Поэтому мы делаем ставку на другое: узкоспециализированную систему, заточенную под конкретный фреймворк и конкретные задачи интеграции. Вот, даже лендос склепали.

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

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

Система у нас состоит из двух ключевых модулей:
1. Генератор кода
2. Фреймворк с четкой структурой, в который этот код встраивается
На вход подается описание желаемого выхлопа, а так же документация целевых систем. На выходе — код, который реализует желаемую интеграцию, встроенную в фреймворк.

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

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

Продолжение следует 👇

Смотрел код — и заметил прекрасное. Зацените, как там проверяется время:

event.createdAt.truncatedTo(ChronoUnit.SECONDS) shouldBe OffsetDateTime.now().truncatedTo(ChronoUnit.SECONDS)

То есть просто отрезают миллисекунды в надежде, что тест «успеет» в ту же секунду. А если через миллисекунду тикнет новая? Ну да, можно же начать резать минуты… или часы…
Так и рождаются моргающие тесты, которые то проходят, то падают — чистое веселье.

Что с этим делать?

Нормальный путь — зафиксировать время через Clock.fixed() или Clock.offset() и передавать этот Clock внутрь всего, что генерирует OffsetDateTime.now(clock).
Красоты мало, зато:
• время контролируется снаружи;
• тесты становятся предсказуемыми;
• и никто больше не бегает от внезапно наступившей секунды.

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

Ещё вариант: не сравнивать даты напрямую, а мерить Duration.between(…) и проверять, что разница в пределах пары миллисекунд. А когда CI сервер начнет тормозить и тесты снова станут моргать — добавите еще пару секунд, делов то.

Ну и последний способ — попробовать замокать статический метод now(), если сможете конечно.

P.S.: Если понадобятся дополнительные лайфхаки по созданию говнокода — зовите, всегда рад помочь.

Типичная разработка