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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наконец-то стоящее обновление 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 знает, когда я плачу.
• 😐 Иногда зову чат, когда всё совсем плохо.
• 😢 Никогда. ИИ — это какая-то секта.

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

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

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

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

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

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

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

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

Что это значит? А то, что теперь можно весело и задорно проводить атаки на цепочку поставок: находим стабильный баг в бестолковом ИИ, регистрируем репозиторий с нужным названием, начиняем его зловредным кодом — и выкатываем в какой-нибудь npm. Остается только дождаться, пока вайбкодеры втащат зависимость себе.

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

Источник

Небольшое пояснение

Вообще, мок — это общее название для тестового двойника, но не совсем точное. Потому что помимо моков (mock) существуют:
• Пустышки (dummy) — используются для заполнения параметров, которые обязательны, но не влияют на сам тест. По сути, это просто заглушки, чтобы код не жаловался, что ему чего-то не хватает. Типа как “пригласить на тусу бывшую, но игнорировать ее всё время”. Если ее дернуть, то получишь по-морде исключение, так как взаимодействие не предусматривалось.
• Заглушки (stub) — возвращают заранее заданные значения, которые нужны тесту. Они не записывают, что с ними происходило, а просто делают вид, что они настоящие.
• Шпионы (spy) — записывают, как с ними взаимодействовали: какие методы вызывались, с какими аргументами. Очень полезны, если ты параноик и хочешь знать, кто сколько раз что вызвал.
• Фальшивки (fake) — это полноценные рабочие реализации, но упрощённые. Например, база данных в памяти вместо реальной (H2 или вообще HashMap).

Настоящие моки пошли из этой статьи. Если коротко, то мок — это такой класс, который знает что он будет протестирован, а также содержит методы для верификации. Его можно получить из spy, прикрутив метод проверки чего было вызвано/сколько раз/с какими аргументами/etc. Примеры можете найти в нашем референсе в классах Mock<Something>

Определений можно услышать тысячи, главное понимать суть.

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

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

Как это работает?
Очень просто: устраиваем контролируемые отказы. К примеру:
⁃ Перестаём слать данные в один из каналов телеметрии
⁃ Забиваем все соединения к БД, как будто пятница и все пошли строить отчёты
⁃ Замедляем или полностью отключаем внешний сервис через какую-нибудь тулзу
⁃ Оставляем один экземпляр бэкенда из десяти
⁃ Ну и другие радости, всё зависит от специфики проекта и ваших SLA

Что происходит дальше? Поначалу, очень часто — ничего. Точнее, внешне ничего. Метрики такие: «всё норм, шеф», алерты мирно спят, в логах тишина. И только редкий вялый WARNING в логах вида «unknown error - operation failed», скромно обозначает, что половина системы уже лежит, а вторая пишет себе завещание. И цель здесь — дотянуть observability до нужного уровня, чтобы алерты орали во всю глотку. Полученные результаты могут быть использованы при организации процесса поддержки и написании соответствующей документации для дежурных админов/разрабов.

Такие учения — это не только способ проверить готовность команды, но и шанс обнаружить серьезные баги (хотя по-хорошему надо бы провести полноценное хаос-тестирование, но и это лучше чем ничего). Потому что если не вы устроите системе праздник жизни — она устроит его сама. В пятницу, в 18:03.

И небольшой лайфхак из нашей практики. Если хотите, чтобы боль преследовала вас на этапе разработки, а не при эксплуатации, то возьмите под один из стендов (для хардкорщиков под препрод) самый дешевый, самый стрёмный хостинг, который только сможете найти. Он постоянно будет сбоить и глючить, зато вы отработаете кучу интересных сценариев, что называется органично. У нас к примеру «отгрызалась» память, терялось сетевое соединение между хостами, отлетали диски и много чего еще интересного. В итоге мы научились реплицировать данные, придумали тулзы для проверки и восстановления консистентности после падений и научились нормально мониторить состояние системы. А самый кек был в том, что машины для прода оказались не сильно надежнее.