Технический долг и рефакторинг: что можно предлагать джуну на первой работе

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

Что такое технический долг?

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

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

Почему джуну важно это понимать?

Многие джуны думают: «Я тут новенький, мне не до этого». Но именно в этот момент ты можешь стать ключевым игроком. Ты не знаешь историю проекта - значит, ты видишь проблемы глазами человека, который не врос в «это всегда так было».

Ты можешь заметить:

• Один и тот же кусок кода копируется в 5 местах.
• Функция из 200 строк делает три разных вещи: авторизацию, отправку письма и логирование.
• Все тесты пишутся вручную, а CI/CD вообще не настроен.

Это не твои ошибки. Но ты можешь предложить решение - и это сделает тебя ценным.

Что можно предложить на первой неделе?

Не пытайся переписать весь проект. Начни с малого. Вот что реально работает:

1. Предложи улучшить один тест. Найди самую хрупкую функцию - ту, что часто ломается. Напиши для неё автоматический тест. Это не просто «тест» - это защита от будущих ошибок. И ты сразу показываешь, что думаешь о качестве.
2. Вынеси дублирующийся код в функцию. Если в трёх местах одинаковый кусок кода - вынеси его. Это не «рефакторинг», это просто уборка. И ты экономишь команде 2-3 часа в месяц.
3. Запиши, что не понимаешь. Напиши в чат: «Я не понимаю, зачем здесь этот костыль. Можно ли это упростить?» Не обвиняй. Просто спрашивай. Часто старшие разработчики сами забыли, почему это так сделано.
4. Попроси добавить задачу в бэклог. Если ты заметил системную проблему - не молчи. Скажи: «Я нашёл, что при каждом изменении в модуле X падает тест Y. Может, сделать задачу на улучшение?» Даже если её не сделают сразу - ты показал, что думаешь на уровне системы, а не только задачи.

Как говорить об этом с командой?

Ты не должен говорить: «Этот код - мусор». Это вызовет сопротивление. Вместо этого используй язык бизнеса.

Вот как звучат правильные фразы:

• «Если мы упростим модуль авторизации, мы сможем добавить вход через Telegram за день, а не за неделю».
• «У нас сейчас 12 ручных тестов. Если мы автоматизируем пять из них, QA сможет сосредоточиться на новых сценариях».
• «Когда я пытался исправить баг в корзине, мне пришлось разобраться в трёх разных модулях. Может, стоит объединить их?»

Ты не говоришь: «Надо переписать». Ты говоришь: «Это сэкономит нам время». И это то, что слышит руководство.

Правило 20%: как не сгореть

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

Ты можешь предложить это и у себя. Скажи: «Я хочу выделить один день в неделю на улучшение кода. Не на новые фичи, а на то, чтобы потом новые фичи шли быстрее». Это не просьба - это предложение. И ты покажешь, что думаешь о долгосрочной эффективности.

Что не стоит делать

Не делай три ошибки, которые ломают карьеру джуна:

• Не переписывай код без согласия. Если ты вдруг переделал модуль, а потом оказалось, что он работает с legacy-системой - ты сломал всё. Всегда спрашивай: «Можно ли это изменить?»
• Не называй код «мусором». Это не твой код. Это код людей, которые работали до тебя. Они делали то, что могли. Ты не должен осуждать - ты должен улучшать.
• Не жди, пока тебя попросят. Ты не джуниор, который просто выполняет задачи. Ты разработчик, который хочет делать лучше. Если ты видишь проблему - скажи. Даже если это просто вопрос.

Рефакторинг - это не роскошь. Это инвестиция.

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

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

Как проверить, что твой рефакторинг работает?

Не жди, пока тебе скажут «хорошо». Измеряй сам:

• Сколько времени уходит на фикс багов? Если после твоих изменений их стало меньше - ты сделал дело.
• Сколько времени уходит на новую фичу? Если раньше на неё уходило 5 дней, а теперь - 3 - ты ускорил команду.
• Сколько человек понимает этот модуль? Если раньше только один разработчик мог его трогать, а теперь - ещё и ты - ты уменьшил риск.

Эти цифры - твоя валюта. Не твои «запросы», не твои «пожелания». А конкретные результаты.

Что дальше?

Ты не обязан всё исправить за неделю. Но ты можешь начать с одного действия. С одной задачи. С одного теста. С одного вопроса.

Представь, что через полгода ты смотришь на код, который ты когда-то считал «непонятным». Теперь ты видишь: «Я сделал это лучше». Это не просто код. Это твоя репутация.

Технический долг - это не твоя вина. Но улучшать его - твоя сила.