"У вас специфический стек - вы с таким работали?" Как я берусь за незнакомые технологии

"У нас довольно специфический стек, местами очень старый. Вы с таким вообще работали?" Этот вопрос я слышу почти на каждой первой встрече, и за ним всегда стоит один и тот же страх: клиент боится платить мою ставку за то, что мои инженеры будут сидеть и гуглить его технологию. А ещё - что редкий или древний стек означает, что помочь я в принципе не смогу.

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

За что вы платите на самом деле

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

Это разные вещи, и разница тут критическая. Знание конкретного фреймворка устаревает. Оно привязано к версии, к моде, к экосистеме, которая через три года будет выглядеть иначе. А способность разобраться в чужой системе не устаревает никогда - потому что архитектурные шаблоны повторяются от стека к стеку.

Очередь сообщений остаётся очередью сообщений, будь это Kafka, RabbitMQ или что-то самописное на таблице в базе. Кеш - это кеш. Планировщик задач - это планировщик задач. Слой данных, конвейер обработки, слой аутентификации - всё это повторяется из проекта в проект. Меняется словарь. Форма не меняется.

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

Почему опыт переносится между стеками

После достаточного количества систем начинаешь узнавать несущие части быстро. Это не магия и не талант - это насмотренность. Через руки проходят десятки архитектур, и в какой-то момент вы перестаёте читать код буквально и начинаете видеть структуру.

Что даёт этот опыт конкретно:

• Вы быстро находите несущие части - те, на которых держится вся система, и те, которые можно игнорировать до поры.
• Вы знаете типовые режимы отказа. Где обычно течёт память, где рвётся консистентность, где спрятана гонка, которая стреляет раз в месяц под нагрузкой.
• Вы отличаете намеренные "странные" решения от случайных. Это, наверное, самое ценное. В любой старой системе есть места, которые выглядят дико. Часть из них - осознанный компромисс под реальное ограничение, который нельзя трогать. Часть - просто накопившаяся грязь. Опыт помогает не перепутать первое со вторым.

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

Как я на самом деле захожу в незнакомую или легаси-систему

Это практическая часть. Когда я беру систему, которую вижу впервые, я иду по одному и тому же порядку. Он выработался на десятках проектов и экономит недели.

1. Читаю контракты и потоки данных раньше кода. API, схемы базы, очереди, точки интеграции. Карта того, как части системы разговаривают друг с другом, говорит больше, чем любой отдельный файл. Код рассказывает, как что-то сделано; контракты рассказывают, зачем оно вообще есть.

2. Сначала нахожу несущие части и денежные пути. Где именно система зарабатывает или тратит деньги клиента, где проходит критичный для бизнеса поток. Остальное игнорирую, пока оно не станет важным. В любой большой системе 80 процентов кода не имеют значения для текущей задачи, и тратить на них внимание в первые дни - расточительство.

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

4. Запускаю, ломаю в безопасной копии, читаю логи. Поведение бьёт предположения. Можно час рассуждать, что делает функция, а можно поднять копию, дёрнуть её и посмотреть. Логи под реальной нагрузкой рассказывают о системе правду, которую код скрывает.

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

6. Явно ограничиваю неизвестное по времени и делюсь тем, что нахожу. Если в системе есть кусок, который мне действительно незнаком, я не растворяю его в счёте. Я говорю: вот здесь мне нужно два дня, чтобы разобраться, вот что я рассчитываю выяснить. Клиент не платит вслепую за "обучение". Он видит, на что уходит время, и может остановить меня, если посчитает нецелесообразным.

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

Прямо про счёт

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

Да, вход в действительно новый, узкий инструмент - это реальные затраты времени. Я не буду делать вид, что читаю любую систему мгновенно. Разница в том, как я с этим обхожусь: я оцениваю этот вход отдельно, называю его вслух и не прячу внутри общего счёта.

Если для вашей задачи мне нужно разобраться в редкой библиотеке или проприетарном протоколе, вы услышите это на входе: "здесь я закладываю столько-то времени на изучение, потому что раньше с этим конкретно не работал". Дальше это ваше решение - идти на эти часы или искать того, у кого этот инструмент уже в руках.

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

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

Честные оговорки

Было бы нечестно закончить на "я разберусь в чём угодно". Это не так, и я не хочу продавать иллюзию.

Есть области, где действительно нужна глубокая, специфическая экспертиза, и быстрого чтения тут не хватит:

• Регулируемое или специализированное железо. Медицинские приборы, промышленные контроллеры с сертификацией, системы, где ошибка стоит жизни или лицензии. Здесь цена ошибки такая, что учиться на ходу недопустимо.
• Экзотические real-time и embedded ограничения. Жёсткий реальный тайминг, работа под аппаратными лимитами, где интуиция из веб-мира просто вредна. Тут нужен человек, который годами жил внутри этих ограничений.
• Глубокие проприетарные платформы. Закрытые системы с многолетней спецификой, где половина знания нигде не описана и живёт только в головах узкого круга людей.

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

Доверие для меня стоит дороже одного заказа. Один честный отказ "это не моя зона, вот кто вам нужен" возвращается тремя проектами, где я действительно полезен. Взяться за то, в чём я слаб, ради одного счёта - это способ потерять и репутацию, и клиента.

Если коротко

• Клиент боится платить за то, что инженеры будут гуглить его технологию. Страх понятный, но адресован не туда.
• Я продаю не знание конкретного фреймворка, а способность быстро прочитать чужую систему и принять в ней хорошие решения.
• Архитектурные шаблоны повторяются между стеками. Меняется словарь, форма остаётся. Опыт переносится именно потому, что он про форму.
• Захожу по порядку: контракты раньше кода, несущие части раньше остального, люди раньше документации, поведение раньше предположений. Работающее не переписываю.
• Реальный вход в узкий инструмент существует - я его называю и оцениваю отдельно, а не прячу в счёте.
• Есть зоны, где нужна узкая глубокая экспертиза. Там я честно говорю об этом и привожу специалиста или отказываюсь.

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