Хаотичная кодовая база перед наймом инженеров: что исправить

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

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

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

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

Обычно этот рисунок видно довольно быстро. Pull request становятся больше, потому что маленькие всё равно неделями висят на ревью. Деплои зависят от одного человека, который «знает шаги». Команда каждую неделю решает одну и ту же проблему в чате, а потом забывает ответ. Баги прыгают от человека к человеку, потому что никто чётко не отвечает за эту область.

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

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

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

Как выглядит хаотичная кодовая база в ежедневной работе

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

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

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

Ревью тоже превращается в путаницу, только по-другому. Pull request висят по три-четыре дня, а потом возвращаются с разными комментариями от разных людей. Один просит рефакторинг. Другой говорит, что масштаб слишком большой. Третий оставляет замечание по стилю и больше не появляется. Никто не принимает чёткое решение, поэтому работа продолжает прыгать туда-сюда.

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

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

Сначала наладьте ответственность, а потом открывайте новые роли

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

Начните с того, чтобы разбить кодовую базу на понятные области, за которые отвечает одна команда. Используйте границы продукта или системы, а не случайные папки. Биллинг, auth, отчётность, мобильное приложение, внутренняя админка и data pipelines гораздо проще в управлении, чем огромные корзины вроде «backend» или «platform».

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

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

Работа между командами тоже должна подчиняться правилу. Выберите одно и используйте его каждый раз. Хорошо работает простой вариант: если задача затрагивает область другой команды, владелец этой области смотрит план до начала разработки и проверяет финальное изменение перед слиянием. Это добавляет небольшую паузу в начале и экономит дни переделок позже.

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

Сделайте деплой предсказуемым

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

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

Ручные шаги — это то место, где обычно начинаются плохие релизы. Если кто-то всё ещё вручную меняет конфиг, запускает database scripts с ноутбука или отправляет детали релиза по памяти, перенесите эти шаги в скрипты или CI jobs. Скрипт может быть неидеальным, но всё равно поможет. Чеклист, зависящий от памяти, рано или поздно ломается.

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

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

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

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

Сделайте code review быстрым и понятным

Медленные ревью учат людей неправильным вещам. Они перестают просить обратную связь заранее, копят огромные pull request и переносят стресс в процесс деплоя.

Большинству команд помогает ограничение по размеру. Pull request должен описывать одно изменение, а не неделю смешанной работы. Если в PR одновременно лежат исправление бага, рефакторинг и изменение схемы, ревьюеру приходится гадать, что здесь самое важное. Держите изменения достаточно маленькими, чтобы их можно было прочитать за один заход. Многие команды неплохо справляются, если остаются в районе 200–400 изменённых строк, за исключением случаев, когда это в основном сгенерированный код или перенос файлов.

Если изменение больше этого, разбейте его специально. Уберите очистку в один PR. Изменения поведения вынесите в другой. Большие переименования и переносы файлов лучше оставить отдельному ревью, иначе они скроют настоящий риск.

У ревьюеров тоже должна быть узкая задача. Им нужно задать несколько базовых вопросов. Решает ли изменение заявленную проблему? Может ли оно сломать существующий путь, поток данных или деплой? Есть ли тесты там, где риск реальный? Достаточно ли код понятен, чтобы следующий инженер мог безопасно его менять?

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

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

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

Если ревью кажется тяжёлым, ответ обычно не в том, чтобы добавить ещё ревьюеров. Ответ — в более маленьких изменениях, более чётких стандартах и более быстрых ответах.

Используйте простой план уборки на первый месяц

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

Полезный первый месяц может выглядеть так:

1. Неделя 1: Проследите, как работа движется сейчас. Запишите владельцев сервисов, шаги релиза, кто утверждает pull request и где работа застревает на дни.
2. Неделя 2: Уберите самый громкий источник боли. Если деплой ломается из-за одного скрипта, который понимает только один человек, замените его на понятную повторяемую команду и короткий чеклист.
3. Неделя 3: Запишите правила, которые люди держат в голове. Новые сотрудники должны знать правила именования, правила веток, ожидания по ревью, шаги отката и к кому обращаться, если что-то ломается.
4. Неделя 4: Проведите одно небольшое изменение через весь путь. Возьмите крошечную фичу или исправление бага и доведите его от тикета до ревью и релиза без спасательных операций в приватном чате.

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

Лучший тест — скучная работа. Попросите одного инженера выкатить что-то небольшое, например добавить поле во внутреннюю форму или изменить один шаблон письма. Посмотрите, где он начинает сомневаться. Если он спрашивает: «Кто отвечает за этот сервис?» или «Из какой ветки я должен выкатывать?» — вы нашли правило, которое всё ещё живёт только в чьей-то памяти.

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

Реалистичный пример из растущей команды

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

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

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

Команда на две недели приостановила найм и сначала починила поток работы. Они назначили у сервиса billing одного понятного владельца и одного запасного. Перенесли шаги деплоя в CI, чтобы процесс жил в репозитории, а не на ноутбуке. Написали короткий чеклист релиза с шагами отката. И ещё изменили правила ревью: для каждого pull request нужен был один ревьюер из области сервиса и одна чёткая причина любого запрошенного изменения.

Этого оказалось достаточно, чтобы всё стало спокойнее. Обычный релиз перестал звучать как «Сэм может запустить это сегодня вечером?» и стал выглядеть как «проверки прошли, ревью завершено, выкатываем из pipeline». Люди стали меньше ждать и меньше гадать.

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

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

Ошибки, которые поддерживают хаос

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

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

Ещё одна частая ошибка — нанимать сеньоров и ждать, что они разберут командную политику за счёт опыта. Хорошие сеньоры могут многое улучшить, но они не должны угадывать, кто принимает продуктовые решения, кто отвечает за рискованные сервисы и чьё одобрение действительно важно. Если руководители оставляют это размытым, сеньорские наймы тратят время на переговоры вместо работы.

Размытые правила утверждения тоже вредят, только тише. Команда говорит, что хочет гибкости, и поэтому никто не записывает, кто что ревьюит, когда нужен второй ревьюер и что блокирует деплой. Это звучит удобно, пока один pull request не висит три дня, другой не выходит за десять минут, а новый сотрудник не понимает, что процесс зависит от настроения.

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

Небольшой пример хорошо это показывает. Если новый backend-инженер приходит в понедельник и всю неделю спрашивает трёх разных людей, как безопасно выкатить одно изменение, у команды в первую очередь проблема не с кодом. У команды проблема с руководством. Исправьте это, и код станет проще улучшать.

Быстрая проверка перед тем, как отправлять офферы

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

Используйте короткую проверку:

• Спросите трёх инженеров, кто отвечает за код, с которым они работали на этой неделе. Если вы получите три разных ответа, ответственность всё ещё живёт в головах людей.
• Спросите, сможет ли команда выкатить изменения, если обычный человек, который всех спасает, уйдёт на день. Если деплои останавливаются, когда один человек офлайн, у вас ещё нет настоящего командного процесса.
• Проверьте процесс ревью. Ревьюеры должны отвечать в понятный срок — например, за несколько рабочих часов для обычных изменений или за один рабочий день для крупных pull request.
• Спросите у новичка, где лежат шаги релиза и шаги отката. Если ему нужны пять ссылок, два старых сообщения и личная записка от кого-то из команды, процесс всё ещё слишком хрупкий.

Представьте, что следующий сотрудник приходит в понедельник и должен обновить billing в среду. Он открывает репозиторий, но никто не согласен, кто отвечает за эту область. Его pull request висит день, потому что ревью зависит от одного занятого лида. Потом он узнаёт, что шаги релиза лежат в устаревшем документе, а шаги отката — в чьей-то памяти. Это не онбординг. Это задержка с зарплатой.

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

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

Что делать дальше

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

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

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

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

Если ответственность, инфраструктура и процесс ревью ломаются одновременно, не сваливайте этот хаос на нового менеджера или сеньора и не надейтесь, что он сам всё разрулит. Иногда короткая внешняя перезагрузка быстрее. Oleg Sotnikov на oleg.is работает со стартапами и небольшими командами над архитектурой, инфраструктурой, delivery flow и AI first development — это как раз тот набор, которому часто нужно внимание до начала найма.

Нанимайте после того, как базовые вещи начали работать. Когда одна команда может объяснить ответственность на одной странице, выкатывать изменения без драмы и проводить pull request за часы, а не за дни, вы уже гораздо лучше готовы к росту.