🎯 Зачем спрашивают
Задача интервьюера понять, насколько системно кандидат подходит к вопросу рефакторинга кода, насколько процесс систематизирован. И видит ли кандидат бизнес-приоритеты (рефакторинг ради пользователя, а не ради «красоты» кода).
📝 Ответ
Коротко:
- Определить цели и задачи рефакторинга (Зачем?)
- Определить критерии оценки изменений (Как поймем, что стало лучше?)
- Зафиксировать границы рефакторинга (Что? Где?)
- Покрыть тестами участок кода, которые рефакторим (Как понять, что все ок после изменений?)
Подробнее:
Прежде чем бросаться рефакторить код, следует определить: проблему, цели и задачи рефакторинга.
Частыми проблемами могут быть:
- долгая сборка проекта
- долгий процесс деплоя
- медленное выполнения и обработка данных
- крайне сложная поддержка кода и большая когнитивная нагрузка при внедрении изменений
- дублирование логики
- высокая связанность
- нечитабельность
- отсутствующие тесты
Далее следует провести анализ текущей системы. Если вы опытный разработчик, то свои первичный ощущения, что что-то идет не так, вы превратите в артефакты:
- диаграммы зависимостей модулей;
- UML / sequence diagrams для отображения связей;
- метрики (coupling, cyclomatic complexity, покрытие тестами).
Это помогает превратить субъективное «код плохой» в объективные и наглядные данные для команды и бизнеса.
Как только мы определились с целью, следует определить критерии оценки наших будущих действий. Это нужно для:
- бизнеса, так как именно бизнес выделяет ресурсы (время и деньги) и ему нужно знать, на что они будут потрачены
- разработки, ведь мы должны понимать как нам оценить наши действия и не сделали ли мы хуже.
Если говорить про производительность, то ее так или иначе можно изменить:
- за сколько времени проект собирается
- за сколько времени проект деплоится
- за сколько времени прогоняются тесты
- сколько памяти занимает собранный проект
А вот удобство поддержки (или же developer experience) не просто измерить, но можно по косвенным признакам ().
Далее следует очертить границы рефакторинга. Какие модули или части приложения будут подвержены изменениям. Это необходимая декомпозиция, чтобы не броситься прямиком на амбразуру пушки. Любой крупный рефакторинг лучше делать кусками. Так будет и вам легче, и коллегам будет проще (потому что процесс разработки никто не останавливал), да и ревьюить будет проще.
Финальный шаг — покрытие тестами. Тут все просто: рефакторинг без тестов — бой вслепую, что кратно повышает риск обнаружение критических багов на реальных пользователях.
- Middle: рефакторит локально (функцию/модуль), думает в терминах «код стал чище».
- Senior: думает про границы, декомпозицию, бизнес-приоритеты, переиспользуемость, тесты и стоимость.
⚖️ Компромиссы
- Не всегда рефакторинг оправдан с точки зрения бизнеса. Рефакторинг одного участка работающего кода может занять столько же времени, сколько и запуск нескольких фич
- Бизнес мыслит не кодом, а цифрами. Зачастую необходимость рефакторинга следует “продавать” или продавливать менеджерам
- Не каждый код можно отрефакторить за разумное время. Проще переписать с самого 0. А вот сможете ли вы это сделать и будут ли у вас на это ресурсы — другой вопрос
- Прежде чем рефакторить код, нужно понять, что и как он делает. Можно встретить крайне сложный и запутанный доменный код, работающий по “божьему” велению. Как правило, документации на такой код нет, а носителями древних знаний — пара человек, стоявших у истоков написания приложения. И то в лучшем случае.
🔎 Встречные вопросы
- Как вы убеждаете бизнес выделить время на рефакторинг?
- Какие инструменты помогают вам контролировать качество кода после рефакторинга?
- Как понять, что стоит все же писать приложение с 0, а не тратить время на рефакторинг текущего кода?
🚩 Красные флаги
- Если в процессе выполнения задачи вижу, что с кодом что-то не так, то в моменте его и правлю
- Создаю отдельную ветку и правлю то, что мне не нравится
- Да все просто — перепишем с 0.
🛠 Практика
📚 Источники / ссылки
- Refactoring: Improving the Design of Existing Code (с) Martin Fowler