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

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

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

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

Недавно принесли проект на аудит, насколько он готов для запуска в прод. Вроде бы ничего сложного: бекенд, фронт, мобилка и немного вспомогательных штук. Но оказалось, что весь этот функционал размазан по 50+ репозиториям.

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

Мы не раз говорили: если нет веских причин дробить код – начинайте с монорепозитория. Так проще контролировать зависимости, синхронизировать изменения и поддерживать проект (закон Конвея все еще работает). А когда действительно понадобится — тогда уже можно будет выдернуть кусок в отдельный репозиторий.

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

Внимание, годнота! Слушатель наших обучалок Артем протащил таки то, о чем мы говорим и теперь ищет себе коллегу.

Наша команда ищет Backend Java разработчика!

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

В нашей работе мы используем:
- EventStorming — для глубокой проработки бизнес-процессов
- Clean Architecture — для построения масштабируемых и поддерживаемых приложений
- Domain Driven Design — для создания моделей, максимально соответствующих бизнесу
- Trunk-based development — для эффективной и безопасной работы с кодовой базой
- Парное программирование — для повышения качества кода, улучшения понимание кода командой

Были бы рад видеть в команде единомышленника, которому интересно работать без боли и сожалений.
Если заинтересованы пишите @artem_poskrebyshev

В личной беседе Артем сказал, что вообще топчик получился, пожалуй пригласим его на стрим, пусть все сам расскажет.

Особенно приятно когда ребята после курсв могут внедрить эти практики! Отличная работа, Артем! знаю что было не легко!

Походил слегка по собеседованиям, ужаснулся количеству вопросов про хибер (его ещё кто-то использует?!) и решил… что очередное корпоративное болото подождёт. Последние полтора года махания веслом под крики «ДАВАЙТЕ БЫСТРЕЕ!» отбили желание не только работать, но и жить.

Поэтому временно переключаюсь на творчество и эксперименты.

Что в планах?
- Видосики – уже записал несколько видосиков (есть душные, есть не очень).
- ИИ – продолжаю эксперименты, хочется довести до практического применения и показать вам
- Стримы – в планах общаться с крутыми людьми из индустрии, уже договариваемся
- Курсовой проект – самое сочное! Небольшая команда строит приложение, используя DDD, чистую архитектуру, trunk-based development, обмазывает его безопасностью, нагрузками и мониторингом, а потом пихает в условный прод. 🚀 Пока только-только стартуем, надеюсь, участники не посадят друг друга на перо.

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

Оставайтесь с нами – будет жарко! 🔥

Вообще, кстати, есть одна мысль, которая пришла в голову

А вы вообще задумывались, что то, что люди радуются, когда пишут заявление на увольнение - эт вообще-то показатель лютейшей несостоятельности компании?

А это ведь норма современной жизни. Я буквально отовсюду слышу типа «Блин, я на свободе», «Ура, я так счастлив(а)», «Лучшее решение в моей жизни» и так далее

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

Они ловят кайф от работы, представляете? Вот вы давно ловили кайф от своей работы? Ну вот прям чтоб по-настоящему? Чтобы прям такой встал с утра и такой блин как я щас с кайфом поработаю. Спрашиваю, кстати, без сарказма, уверен, что такие люди есть

Но, как ловить кайф от постоянных зум созвонов?

Как ловить кайф от неадекватных менеджеров, которые сами не помнят, что хотели сделать вчера?

Как ловить кайф от задач, которые даже блин тем, для кого они якобы предназначены, не нужны?

Как ловить кайф от вредительства?

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

И этот механизм давится нами сознательно, ну потому что жизнь такая, надо на что-то жить, это они виноваты, я просто исполнитель и тд и тп

Расплатой как раз становится вот такая вот нежизнь. Когда уход с работы воспринимается буквально как освобождение от рабства

40 часов в неделю (по факту еще больше) ты находишься в этом самом узаконенном рабстве. В ментальной тюрьме. Интересно даже узнать стоит ли оно той зарплаты? Ну мне можно не отвечать, себя-то не обманешь

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

У нас было 2 джиры, 75 bpmn-диаграмм, 5 менеджеров, пол-ставки админа и целое множество баз данных всех сортов и расцветок, а также Java, Kotlin и Spring. Не то что бы это был необходимый запас для проекта. Но если начал кодить, становится трудно остановиться. Единственное что вызывало у меня опасение - это suspend-методы. Нет ничего более беспомощного, безответственного и испорченного, чем корутины в проде. Я знал, что рано или поздно мы перейдем и на эту дрянь.

Мы с Женей всегда говорили: важно не просто делать, а действительно понимать, что ты делаешь и как это работает.

И вот CEO GitHub Томас Дохмке на VivaTech 2025 в подтверждает это Париже:

• AI‑ассистенты позволяют баловаться с вайбкодингом — быстренько запиливаем, не погружаясь слишком в пучины технологий.
• Но это только начало. Без глубокого понимания системы стартап сложно масштабировать — чтобы привлечь раунды инвестиций, нужна техническая команда с реальными навыками
• По словам Томаса: «Ценность вашего стартапа определяется не тем, что вы можете собрать задёшево» и «нужно понимать, когда использовать ИИ‑подсказку, а когда писать код самому»

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

Пить чай с бухгалтерией иногда важнее написания кода

Вспомнилась другая история примерно из 2014 года, как я прикручивал мастеркард к одной большой платежной системе. Удивительным образом часть моей работы заключалась….в испитии чая вместе с бухгалтерами.

Почему так?
У меня не было отдельных системных аналитиков, которые бы рассказали как какая авторизация/рефанд/реверсал/что угодно будет отражена на счетах. Приходилось разибраться в тонкостях процесса, бухучета и хрен знает чего еще. На мониторе у меня были налеплены стикеры с основными терминами, а я мог объяснить логику укладки транзакций не хуже банковского аналитика. По итогу это был самый пустяковый проект для меня с точки зрения доработок и допилок, хотя предметкка нифига не простая

Как приучить python-котиков к лотку

Как вы знаете, я не очень жалую питон. На это есть 2 основные причины
- Он слишком много разрешает. Можно поприседать задницей на клавиатуру и интерпретатор исполнит получившийся результат. Сначала это выглядит как ВОООУ ГИБКОСТЬ!!11, а потом нужны еще +3 человека, чтобы эту гибкость выпрямить
- Динамическая природа языка. Её можно поправить, но только отчасти

Так вот, проект куда меня позвали спасать был написан на питоне. Он был свеж и можно сказать greenfield, но спустя совсем непродолжительное время начались классические проблемы — код перестал быть поддерживаемым: запутались в цепочках вызовов и перестали понимать что происходит

Что нас в итоге спасло:
- Разделили убер-классы с бизнес-локикой на небольшие классики, похожие на UseCase
- Внедрили статическую типизацию через mypy и заставили ее работать, а не просто формально присутствовать (хотя к работе mypy тоже есть вопросики, но это обусловлено самим языком и все же лучше чем ничего).
- Впоследствии еще сделали прото-объекты-значения, чтобы понимать какой float что обозначает в параметрах метода
- Приделали returns . Стало понятно что можно ожидать от метода. Кстати есть плагин для mypy
- Обмазали правилами из pylint . Самое эффективное правило у нас - ограничение цикломатической сложности. Поскольку проект был MLный, то нередко можно было встретить код с 10ю вложенными циклами, что уводило читабельность и понимаемость в отрицательную зону

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