Божественный костыль для тех, кто не умеет

Ах, ИИ — новая волшебная таблетка! Достаточно добавить «с ИИ» в описание проекта, и вот уже инвесторы бегут со следующей порцией подливы, клиенты оттягивают вам резинку труханов, чтобы напихать хрустящих купюр, а код сам себя пишет. Напоминает вам что-то? Например, NoSQL в 2010-м, микросервисы в 2013-м и блокчейн в 2017-м — только вид сбоку.

Конечно, есть команды, которые реально получают буст от ИИ. Но сюрприз-сюрприз: у них и до этого всё было неплохо — и требования вменяемые, и в коде разобраться можно.
А есть другие. Те, кто уже в своём коде не разбирается, но свято верит, что вот-вот появится ИИ, в который можно запихнуть весь проект, нажать кнопку «Сделать хорошо» — и вуаля, можно идти пить тыквенный латте (это не шутка, я слышал такие разговоры).

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

Мы все живые люди, а не собственность работодателя.
Работа — это просто работа. И многих HR сам факт этого доводит до микроинсульта.

Если бы не кредиты, ипотеки и не современная экономическая система —
большинство из нас вообще бы не работали, а занимались бы чем-то реально интересным.

Будем честны: какой вообще интерес — до конца жизни перекладывать JSON на одной из этих джейсоноразвесочных фабрик, коими стали огромное количество проектов?

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

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

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

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

Но вообще мне повезло, со мной хотя бы пообщались.

Если вы тоже работаете в компании,в которой главный продукт -- производство обсуждений, ставьте лайк

ИИ снова в новостях: то удалил БД, то слил данные. Ничего удивительного — ИИ может "глючить".
Но вот что странно: никто толком не понимает, как он работает (исследования только начались), а его уже внедряют повсюду. Что же может пойти не так?

P.S.: А ещё это огромное хранилище уязвимостей — под LLM даже свой OWASP Top-10 появился.

Иногда у них даже получается

Cultural map на пальцах. И без переломов

Недавно мой коллега, коренной британец, с пафосом викторианского джентльмена пожаловался на американцев в стиле «Ну тупые». Его пример: в Британии — horse riding, в американском английском — horseback riding. Мол, зачем эти уточнения? Ну и так же ясно, куда именно надо садиться на лошадь. Не на хвост же, хотя, конечно, в жизни всякое бывает.

Но на русском это вообще будет «верховая езда». И тут мы пошли ещё дальше: мы даже не уточняем, на ком или чём мы там верхом. Всем и так понятно, что не на корове (а вот когда Шурик в Кавказской пленнице на осле ехал — это все еще верховая езда?)

Это, кстати, отлично иллюстрирует книгу The Culture Map. По мнению автора, одна из ключевых разниц между странами — это сколько контекста подразумевается в сказанном.
• У американцев контекста почти нет: что сказали, то и имели в виду.
Пример: «Let’s meet at 3 p.m. at Starbucks on 5th Avenue» — это буквально приглашение встретиться в 15:00, в конкретном Старбаксе, на конкретной улице.
• У британцев контекста больше: надо понять подтекст, тон, скрытую вежливость.
Пример: «We should get together sometime» — значит «Мы, конечно, никогда не встретимся, но я вежливо изображаю заинтересованность, чтобы не показаться хамом».
• В России уровень контекста ещё выше: половина смысла в интонации, а вторая половина — в том, что не сказано.
Пример: «Надо бы встретиться» — в зависимости от тона это может значить:
1. «Я тебя реально хочу увидеть»
2. «Мы больше никогда не увидимся»
3. «Ты мне должен денег»
4. «Я уже возле твоего дома»

В общем, чем восточнее, тем меньше слов и тем больше догадок. Книга однозначно рекомендована к прочтению.

Вакансия: Платформ-лид в Яндекс Крауд

Компания Яндекс открыла позицию платформ-лида.

В описании упоминаются:
• DDD
• Clean Architecture
• Trunk-based Development
• Event Storming
• TDD

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

Из хорошего: количество собеседований сократили, так что можно попробовать свои силы;

По всем вопросам пишите CTO @Dzirtik

P.S.: Это не реклама, а вакансия от проверенных людей. Публикуем, потому что таких позиций на рынке 3,5 штуки.

с недавнего собеса:

- как работают слои в докеробразах, кэш?
- {мои ответы}
....
A FEW MOMENTS LATER
- {мои вопросы}
....
- а как вы деплоитесь на прод?
- rsync

Снова побуду капитаном очевидностью.
Намедни обсуждали вопрос сравнения (equals) агрегатов. И здесь важно помнить: сравнение — это всегда контекстно зависимая операция.

Почему так?
Потому что невозможно сравнивать «вообще» — всегда есть цель, ради которой мы это делаем.

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

a === b

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

a.id == b.id

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

a.id == b.id && a.field1 == b.field1

Причем механизм сравнения полей тоже может отличаться в зависимости от контекста


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

Это, кстати, один из частых источников ошибок в проектах: мы пытаемся придумать «универсальный способ сравнения», а потом обнаруживаем, что он не подходит в половине случаев.
Поэтому каждый раз, когда возникает вопрос сравнения, полезно начать с простого: для чего мы это делаем?

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

Value Object. Казалось бы, что может быть проще?
Паттерн элементарный, тесты пишутся очень просто, всё логично и прозрачно. Но на практике именно с него начались настоящие трудности.

Почему? Потому что Value Object требует не просто «обернуть данные», а заранее продумать все варианты валидации и граничные условия.
Если раньше хватало поставить что-то вроде @NotBlank в контроллере и надеяться, что кто-то потом в сервисе провалидирует (нет), то теперь приходится разбирать детали:

- Какой должна быть минимальная и максимальная длина имени (к примеру, азиатское имя может состоять из одной буквы)?
- Допустимы ли цифры или спецсимволы? (а если человек зовётся «X Æ A-12 »? Представляю что испытали разработчики государственных систем США увидев ТАКОЕ)
- Что делать с иностранцами: если имя написано латиницей, должна ли и фамилия быть латиницей?
- А если человек решит использовать двойную фамилию через дефис? (и не один раз).

Даже такие на первый взгляд простые сущности, как ФИО, внезапно превращаются в головоломку.

Хорошо, когда у нас есть чёткие и формализованные правила валидации — например, для ИНН или паспорта. Но даже здесь не всё так очевидно.
Даже если формат существует, он далеко не всегда прост.

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

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

В итоге даже самое базовое поле уже не сводится к «строка не пуста». Оно превращается в полноценное проектное решение, за которым стоит куча вопросов, дискуссий и иногда ощущение, что проще сменить профессию.

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

В комментах к прошлому посту справедливо спросили: а зачем вообще такая строгая валидация? Хороший вопрос. Давайте разберёмся.

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

Второй сценарий — когда объект реально участвует в предметной области. И вот тут начинаются настоящие приключения.

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

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

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

🔥 В следующий четверг иду в Книжный клуб .rar обсуждать (внезапно!) выгорание. А поскольку я в этом деле спец (горел уже раза три) — есть чем поделиться 🙂

📚 Книжный клуб .rar — это сообщество айтишников и увлечённых людей, где вместе читаем книги по разработке и другим темам. Каждую неделю — по 1–3 главы, плюс живые обсуждения, где новички и эксперты делятся разным взглядом на идеи.

📅 Когда: 11.09.2025 в 20:00 по МСК (следующий четверг)
📍 Где: Книжный клуб .rar

Всем привет!

Напоминаем, что через час (20:00 по Москве) у нас состоится гостевой выпуск, в рамках которого мы обсудим с Евгением Лукьяновым из "StringConcat" темы вокруг выгорания!

Запасайте печеньки, задавайте ваши вопросы по ссылке, и ждём вас на грядущем эфире!

🔗 Ссылка на подключение: Толк

Обещал видоски - первый пошёл. Разбираемся как быть с валидацией на беке, как сделать ее консистентной между системами, причём тут property testing и WAF.

ВК | YouTube

В опросе всего 5% выбрали релокацию как способ увеличить доход. Пять процентов! Видимо, остальные 95% верят, что «счастье не в деньгах». Или в их случае — «счастье не в переезде». Но давайте честно: этот пункт явно недооценили.

Релокация ≠ «с концами»
Не обязательно сразу жечь мосты и продавать бабушкину дачу в Рязани. Можно рассматривать это как «длительный рабочий туризм». Только вместо магнитиков домой привезёте опыт, деньги и новые ругательства от чтения индусского кода в оригинале.

Куда ехать?
Если вы доросли до уровня senior developer и ещё не обзавелись детьми, то вам прямая дорога в Сингапур, ОАЭ, Гонконг или Швейцарию. Там и зарплаты жирные, и налоги низкие. Правда, иногда налоги настолько низкие, что социальная защита тоже где-то на уровне «держитесь, там вы справитесь».

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

Почему без детей?
Потому что в странах с низкими налогами детские садики и школы тоже низкотаксированные — то есть платные. Тысяча долларов в месяц за школу — и вся выгода от низких налогов испарилась. И золотого унитаза в этих школах не будет. У моих детей в школе (в Сингапуре) кондиционер есть. Но один и в кабинете директора.

Корни и любовь до гроба
Здесь без розовых очков. В этих странах вам рады, пока вы приносите пользу. Как только вы состаритесь, потеряете работу или решите «жить для себя» — чемодан, вокзал, родина. Это не романтика, это чисто деловые отношения. «Любовь» строго до окончания рабочего контракта.

Сколько платят?
Очень примерно:
• Сингапур, ОАЭ, Гонконг: 70–120k USD в год.
• Швейцария: по слухам, немного щедрее — 90–120k.

Бонусы (кроме зарплаты):
• Нетворкинг. Вряд ли вы подружитесь с местными, но любой белый человек для другого белого в этих странах — уже «друг, брат и почти сестра».
• Опыт международной разработки. И это реально ценится. Как сказал один мой менеджер в Сингапуре: «Сергей, не придирайся на собеседованиях к людям, которые уже сюда приехали. Если они пробились в Сингапур — они и так топ».

Какую страну вы бы порекомендовали?