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

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

Кажется, вы уже заметили, найм в айтишечке — это не просто сломанная система, это кома. ИТ-рекрутинг сегодня — это олимпиада по унижению кандидата, причем очень часто оторванная от жизни. На собеседовании ты вертишь деревья, пишешь алгоритмы, а потом выходишь на работу… и месишь ЖСОНы.

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

• В команде — джуны-аутстафферы, проданные по прайсу помидоров. Их погоняют два уставших старшака, один из которых ушёл в отпуск и, возможно, уже не вернётся.
• Верховный архитектор в перманентной войне с вашим менеджером. Каждый созвон заканчивается словами «мне не нравится, переделывайте» без каких либо аргументов.
• Критичные зависимости и сервисы? Их нет, есть только клятвенные уверения, что они появятся к вашему релизу (нет).
• Бюджета на информационную безопасность нет. Можно повесить амулет на сервер.
• Девопс — это человек-загадка, которого выделили вам на 0,2 ставки и он их тратит на дейлик.

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

ИМХО вот об этом неплохо бы спросить на уровне хотя бы сеньора. А не “сколько времени займет разворот бэ-дерева, если вы к нему привязаны”.

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

Этим летом я завершаю работу в команде разработки электромобиля Атом, где последние 1,5 года руководил группой разработки. Посему, открыт к интересным предложениям.
Что умею и люблю:
🔹 Собирать и растить команды
🔹 Выстраивать процессы разработки — от требований до вывода в продакшен и из него
🔹 Внедрять DDD и чистую архитектуру на практике
🔹 И ещё много всего, о чём можно поговорить лично
Если знаете крутые проекты или ищете человека с моим опытом — пишите в ЛС @elukianov. Отправлю резюме, расскажу подробности.
Спасибо, что читаете! ❤️

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

Итак, второе открытие: «Похоже, вся индустрия живёт неправильно».
Открытие случилось на курсе по Large-Scale Scrum (он же LeSS) — где рассказывают, как десятки команд в большой организации должны не сожрать друг друга, а как-то взаимодействовать. Вроде бы пошёл узнать про масштабируемый agile, а в итоге залип на самом обычном скраме. Потому что когда тренер начал рассказывать, как на самом деле должен быть устроен нормальный скрам, зал начал слегка дымиться.

Люди вскакивали с мест, ударяли кулаками по столу и кричали:
— Нет, ну оно так не работает!
А тренер невозмутимо, с лицом дзен-мастера, объяснял:
— А вот так оно имеено и работает. Потому что так и задумывалось.

И ты сидишь такой, и в голове проносится:
«Ага, значит не у нас одного daily превращается в ежевечерний дайджест событий за неделю».

- Оказывается, команда вообще-то должна вместе и сообща работать над одной проблемой, а не просто набирать в спринт разрозненные тикеты, как в супермаркете на кассе самообслуживания.
И тогда daily standup перестаёт быть этим унылым «Вера делала таск 123, сегодня делает его же, и завтра, вероятно, будет продолжать с тем же успехом»,
а становится местом, где люди обсуждают, что на самом деле важно — делятся инсайтами, блокерами, помогают друг другу. Живут, в конце концов.

- Или вот ещё: разработчики, оказывается, сами должны разговаривать с кастомерами. Да-да, голосом. С ртом.
А не строить форт из бизнес-аналитиков, чтобы не дай бог не услышать, как реальный пользователь говорит:
«Вот здесь у вас неудобно».

Но вернёмся к первому открытию. Оно произошло после прочтения книги по DDD.
Я вдруг понял: бизнес и код — это не противоборствующие силы. Это не Джедаи и Ситхи.
Это бизнес говорит, каким должен быть код. И ты такой:
«Подождите… что, мы не просто адаптируем бизнес под архитектуру, а наоборот?!»
И вот тут голова сделала пум.

И самое важное — DDD это не про “жутко тормозные проекты с миллионом слоёв и папкой shared/legacy/backup/do_not_touch_final_FINAL”.
DDD — это на каждый день. Это когда у тебя в голове наконец-то появляется язык, чтобы обсуждать с бизнесом суть, а не прокладку между слоями.

И вот что забавно. Обучение по LeSS напомнило мне наши занятия на курсе по кровавому энтерпрайзу, который без слез и сожалений.
Каждую неделю кто-нибудь из студентов обязательно хочет перевернуть стол и крикнуть:
— Нет! Оно так не работает!
А мы с Женей спокойно, как тренер, объясняем:
— А вот так и работает. Просто вы ещё не пробовали.

И вот от чего вам тоже, скорее всего, захочется перевернуть стол:
– Почему code review только ухудшает качество проекта. Да-да, мы вслух это говорим. И даже объясняем.
– DDD в highload-проекте? Почему бы и нет. Особенно если вы хотите не просто выжить, а понять, что происходит.
– CI/CD — это не сервер, а процесс разработки. А сервера может вообще не быть. Он вам не нужен, если вы не знаете, зачем он.

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

Так что, если вам тоже хочется попереворачивать пару столов — остаётся одно место. Стартуем 31 мая.
Берите каски!

Нам пишут читатели. Живое доказательство что "скрам" -- слово не ругательное. Мы просто его не умеем готовить!

К скраму, как у многих, было скептическое отношение, пока в одно команде сами своими силами не выстроили ровно так, как это в гайдах и описано, не слушая всяких новоиспеченных "скрам-мастеров".
В итоге, команда сама формирует спринт бэклог, цель спринта, работа стала прозрачной, все понимают кто чем занимается. Потому что задачи стали общими, а не у каждого своя. Разработчики вместе с фронтом и дизайнером (разными составами) ходят к бизнесу, вместе рисуют, думают что как.
Оунер занимался только приоритезацией бэклога и приносил в команду проблемы бизнеса исключительно с бизнес формулировкой. А уж как эту проблему решать технически и визуально - задача команды в рамках спринта! Не до спринта, не на груминге/планировании, а именно в спринте.
Как итог, всем понятные оценки (в майках), четкие цели, быстрое и четкое планирование, отсутствие переносов на следующий спринт и даже в рамках эксперимента стабильная работа команды без оунера на протяжении 4 спринтов.

Рубрика: Вредные советы. Антипаттерн: Class Explosion

Описание:
Когда последователи ООП и фан-клуб Мартина Фаулера добираются до кода без присмотра, в проекте возникает эффект ядерного деления: один доменный класс — и понеслась цепная реакция. Через пару спринтов система состоит из 400 классов, каждый из которых делает одну вещь, один раз, в одном месте, и больше никогда.

Симптомы:
• Кодовая база напоминает кладбище интерфейсов.
• Каждый класс делает одну вещь прикрываясь single responsibility principle.
• На прочтение логики одного HTTP эндпоинта уходит столько времени, сколько обычно требуется, чтобы сварить борщ.
• Открываешь PR — там 27 новых файлов. Один валидирует email, другой проверяет, что имя пользователя начинается с заглавной буквы и не содержит проклятий.
• Папки model, core, domain, shared, abstractions, foundation, fundamentals, common, super_common и legacy_common лежат рядом, как косточки динозавра.


Проблемы:
1. Файловая система в панике. Количество дескрипторов растёт, как зарплаты у синьоров на LinkedIn.
2. Компиляция идёт вечность. Зато можно успеть сварить второй борщ.
3. Дебаг превращается в квест. Уже нельзя просто так открыть контроллер, промотать сотни строк кода и найти таки баг в SQL запросе. приходится просматривать множесто файлов.

Лечение:
Мы нашли способ сдерживать бесконтрольное размножение классов. Всё просто: берём ArchUnit или любой другой архитектурный электрошокер и пишем жёсткое правило:

@Test
void `prevent class explosion`() {
    JavaClasses importedClasses = new ClassFileImporter().importPackages("com.yourcompany.yourapp");

    ArchRule rule = classes()
        .should()
        .haveSimpleNameEndingWith("Controller")
        .orShould()
        .haveSimpleNameEndingWith("Service")
        .orShould()
        .haveSimpleNameEndingWith("Entity")
        .orShould()
        .haveSimpleNameEndingWith("Dto");

    rule.check(importedClasses);
}

Теперь всякий, кто вздумает создать Money, UserId или ещё хуже — AggregateRoot, получит предупреждение уже на стадии сборки. А если повезёт — то и выговор.

Вывод:
Классы должны нести гордое знамя своей функции в суффиксе. Всё остальное — ересь. Пусть живут MyAwesomeController, MyAwesomeService, MyAwesomeDto, и никакой самодеятельности.

Сережа забыл добавить, что ни в коем случае незльзя доверять управление транзакциями приложению, всё только в хранимках!