В публичный доступ выложили видосы с конференции за прошлый год. Как всегда много интересных докладов. Для тех, кто хочет стать архитектором, обрести свободу и наконец-то сделать все правильно, рекомендую посмотреть доклад Жизнь архитектора: мечта и реальность (спойлер: вам не позволят) или как спроектантить поиск. Приятного просмотра!

Вернемся с ИИ на землю

Как вы наверное знаете, мы с Сережей не очень жалуем библиотеки для мокирования, типа Mockito или mockk и предпочитаем использовать самопальные моки или фейки в качестве зависимостей. Почему так получилось? Есть несколько причин:

1. Не ломается компиляция. В стародавние времена была проблема с библиотечным API — при изменении сигнатуры ломается тест с сообщением вида «ну ваще-т хотели вернуть экземлпяр вот этого типа, но оказывается не подходит», а не компиляция. Сложнее отловить и поправить
2. Каша вместо теста. Из-за того же API тест становится замусоренным, тяжело уловить суть среди нагромождения doReturn-when-блаблабла. Особенно непонятно становится, если нужно эмулировать сложное поведение.
3. Баги в библиотеках. Натыкались неоднократно. Совсем недавно мы обнаружили что mockk не очень умеет в многопоточное окружение. При попытке использовать экземпляр мока по интерфейсу в разных тестах, запускающихся в разных потоках мы вдруг получили что-то вроде No answer found, хотя тесты не используют общее состояние и моки создаются отдельно для каждой функции тестов. В доке особо на этот счет ничего нет, а то что есть — не работает (если кто-то налетал на такое и победил — напишите в комментах)

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

И еще одно интересное свойство самодельных заглушек — они позволяют нащупать косяки в дизайне. Если у вас не получается сделать мок, он какой-то кривой, косой и неуклюжий, возможно что-то не так в дизайне или где-то сломался SOLID. Библиотеками же можно закостылять все что угодно, например сделать реализацию только одного метода из 100 в итерфейсы или даже сделать мок для статического метода.

Ни к чему не призываем, это как всего лишь наш опыт и мнение, но если есть возможность — попробуйте

Наконец-то стоящее обновление Intelij Idea в первые за много лет.

JetBrains, проснувшись в холодном поту от кошмаров про VSCode, наконец-то выкатил AI-агента в Idea 2025.1. Да-да, спустя тысячу лет после того, как VSCode уже съел, переварил и забыл об этой фиче.

Раньше их «AI» был обычным чатом-попрошайкой. Как будто вы сами не можете открыть ChatGPT в браузере и спросить, почему ваш код такой позорный. Агент в Idea до недавнего времени был просто декоративным собеседником — бесполезный, как лайк от бота в LinkedIn.

Теперь же у нас, внимание, настоящий AI-агент. Ну наконец-то.
— Осведомлен о проекте. Он теперь реально шарит, что у вас в проекте. Можно спросить: «Где тут все контроллеры с POST?» — и он не начнёт молчать, как вы в неловком разговоре.
— Он умеет редактировать код сам. Представьте, не нужно копировать с StackOverflow сообщение из 2012 года и вставлять его в слезах.
— Он работает с несколькими ИИ-моделями: chat-gpt, claude, gemini. То есть, когда одна начнёт нести чушь, можно переключиться на другую, чтобы она несла другую чушь.

Но — держитесь за стул — плагин платный. 10–20 баксов в месяц, чтобы не страдать в одиночку, а страдать вместе с роботом. Правда, продуктивность от этого растёт. Ну или вы просто быстрее закончите работу и раньше начнёте страдать по другим поводам. Win-win.

Опрос
Вы вообще пользуетесь этим вашим AI, или ещё живёте в 2019?
• ❤️ Я раб ИИ: агенты, чаты, письма, тесты, код — всё на боте.
• 🙊Только чаты, но и на работе, и дома — GPT знает, когда я плачу.
• 😐 Иногда зову чат, когда всё совсем плохо.
• 😢 Никогда. ИИ — это какая-то секта.

Сережа клавиатуры уже паяет, я в автоэлектрики пойду. Попробуйте попросить ИИ найти почему двиган троит, кек

Так, вот вам свежее ночное прозрение, пока я пялился в браузер с ИИшкой:

А что если мы не будем просить ИИ написать программу, а попросим его самого стать программой и делать то что нам нужно? Чтобы было понятнее: допустим, вам нужен сервис продажи билетов. Вместо месяцев разработки вы просто говорите ИИ: «Вот схема зала, вот цены, вот эквайринг. Делай красиво, мути бабосики»
И он:
✅ Отдает фронт (и даже адаптивный),
✅ Коннектит базу (и не теряет данные),
✅ Подключает оплату (и не отправляет деньги на свой личный счёт).

Без единой строчки кода, просто добавив ввод-вывод, а ИИ работает как бекенд. Чистая магия: «хочу → получи».

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

Eсли подумать, то раньше все эти задачи выполнялись органическими нейросетями, то есть нами. А сложные способы выражения инструкций — это костыль, чтобы обойти ограничения физического мира и объяснить что нам требуется, ибо по-человечески он не понимал. А теперь понимает и возникает вопрос — а нужны ли вообще посредники?

Что думаете, бред или будущее?

P.S.: уже сейчас можно попросить прикинуться линуксом и чятгпт исполнит линуксячьи команды. Попробуйте

Мнения об ИИ разделились: одни в восторге, другие разочарованы. Мы решили проверить сами. С подельниками взяли небольшой условно-заказной проект, чтобы на практике оценить потенциал ИИ. Бизнес-логика — среднего уровня: не примитивная, но и не запредельно сложная.

Что понравилось:
• Скорость. Код писался в 5–7 раз быстрее, чем вручную.
• Экономия когнитивных сил. Меньше рутины — больше внимания для сложных задач.
• Сложные конструкции. ИИ хорошо работал с Either находил граничные случаи и правильно представлял их ошибками в sealed-классах (не все мои коллеги так умеют), даже объяснять ничего не нужно.
• Декомпозиция. Четкая структура и инкапсуляция упростили генерацию. В анемичной модели это было бы кошмаром с непредсказуемым качеством.

Что требует внимания:
• Предварительная подготовка. Без нормальной аналитики, продуманной структуры, инфры, типовых узлов ничего никуда не поедет
• Слабые места. Например, валидация или другие душные задачи — электромозг часто ошибается, и без навыков написания таких же душных тестов баги можно пропустить.
• Оптимальный дизайн. На некоторых участках даже люди не справились с первого раза.
• Поддержка. С поддержкой и изменеием уже сгенерированного кода есть вопросики, но вроде бы решаемо.

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

Количество людей предсказывающих смерть Закона Мура удваивается каждые 2 года.

Эта шутка заставила меня задуматься а действует ли Закон Мура до сих пор.

Если кратко, то закон мура — империчесое наблюдение сделанное в 1975 году Гордоном Муром: “Число транзисторов на чипе удваивается приблизительно каждые 2 года”.

И график это подтверждает. Мы так и находимся в экспоненциальном росте числа транзисторов.

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

Но это не значит, что прогресс остановился. Инженеры находят обходные пути: многослойные чипы, новые материалы, специализированные архитектуры вроде GPU и TPU, развитие RISC-V. Вместо того чтобы просто «упаковывать» больше транзисторов, мы начали использовать их умнее.

Когда-то мы пришли в разработку просто потому, что это было в кайф. Тогда зарплаты были копеечные, а работа — редкая удача. Максимум — стать админом или, в худшем случае, эникейщиком. Но нас это не пугало. Мы горели своим делом, даже если за него платили копейки. Это было время, когда всё только начиналось, а потом выяснилось, что мы таки купили бетховен за 2 доллара.

Потом индустрия разрослась: agile-коучи, покер-планнинги и другие шарады. Но за всей этой мишурой проекты всё так же страдали от старых, как мир, проблем. Мы с Сережей решили собрать их в кучу, найти общий знаменатель. Так родился проект StringConcat. Мы вложили в него кучу сил и времени и смогли помочь многим. Кто-то смог решить свои проблемы с проектом, кто-то поменял работу на более интересную и высокооплачиваемую, кто-то понял что говнокод — это не норма.

Но сейчас вести образовательную деятельность стало сложно. Мы не инфоцыганы, а практики, которые всё ещё в строю. Однако желание делиться знаниями никуда не делось. Поэтому мы набираем единственную в этом году группу на наш курс Разработка без боли и сожалений, который стартанет в июне. На нем мы с вами вместе
⁃ разберемся как удерживать код в читабельном состоянии автоматически 24/7
⁃ проведем сессию Event Storming на реальной предметке
⁃ узнаем как писать тесты так, чтобы они приносили пользу, а не бесили
⁃ увидим как выглядит реальный коммерческий проект, написаный по канонам DDD и чистой архитектуры
⁃ выясним, почему код-ревью работает не так, как бы нам хотелось
⁃ попробуем написать код по TDD
⁃ и многое другое
Записываться тут. Увидимся!

Немножечко откровений от Капитана Очевидность.

Как вы наверное в курсе, существует 2 способа задания идентификаторов.
- Естественные идентификаторы, которые натурально идентифицируют объект. Н-р СНИЛС, SSN, номер паспорта.
- Суррогатные идентификаторы, которые вводятся для того, чтобы просто различать сущности друг от друга (вообще, некоторые деятели считают идентификаторы протекающей абстракцией, но сейчас не об этом).

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

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

На стриме был вопрос — можно ли заменить в e2e-тестах реальную зависимость на двойника (заглушку, мок и т.д.). Видимо, мы недостаточно подробно объяснили свою позицию, потому что от главного QA шлюпки, где я гребу пришел комментарий, что такой подход — харам. Давайте разбираться.

E2e-тесты действительно лучше проводить с реальными зависимостями, но в жизни бывают разные ситуации, например:
- Тестовых подключений может не быть. Провайдер не предоставляет такую возможность. Обычно демо-аккаунт существует, но не всегда. Приходится выводить в прод под фиче-флагом и отлаживаться на месте.
- Нет доступа к тестовым подключениям. Это подвид предыдущего случая. Бывают ситуации, когда тестовый контур изолирован от интернета, и вызовы вовне невозможны.
- Тестовые подключения нестабильны, и получить “зеленые прогоны” затруднительно. Иногда для демо-стенда выделяется слабый сервер, который подходит только для отладки подключения, но не для постоянного тестирования.
- E2e-тесты можно разделить на уровни. На одном уровне проверяется взаимодействие микросервисов А, Б и В, на другом — взаимодействие системы с внешним сервисом Д. Набор сценариев будет различаться между уровнями. Делается с целью возможности запуска тестов например на локальной машине, где внешние сервисы по какой-то причине недоступны
- Сложность или невозможность приведения внешней системы в нужное состояние. Например, для подтверждения заказа во внешнем сервисе требуется ручное воздействие оператора, а API для изменения состояния отсутствует.
- Высокая стоимость запросов к API. Тестовые запросы тоже могут тарифицироваться. В таких случаях можно разделить тесты на уровни и в некоторых сценариях использовать заглушки.

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

На стриме обещал поделиться статистикой и анализом по багам. В итоге, в нашем проекте типовой баг на бекенде стоит примерно 6,5 часов работы команды - описать баг, назначить исполнителя, поправить, перепроверить, etc. Добавьте сюда время на коммуникацию, переключение контекстов и выйдет почти один рабочий день. При этом тест, который бы предотвратил появление бага пишется/дорабатывается максимум 30 минут (конкретно в нашем проекте). Вот такая интересная математика

https://youtube.com/live/NUBvpA1Dqjo?feature=share погнали!

Стрим будет сегодня в 18:30 мск, ссылку пришлем перед началом

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

Ну что, признавайтесь, у кого так же на работе?

И это было бы смешно, если бы «скрам мастера» не считали что это действительно так и должно работать