Каждому разработчику это знакомо: наследуешь кодовую базу, а на ее кухне поработало так много поваров, что классы раздуты, методы разрастаются, и мысль о рефакторинге всего этого — доработать, сделать эффективнее — представляется одновременно захватывающей и неосуществимой.
С чего же начать? Как справиться, не попав в ловушку «ползучего улучшизма»?
Сложно? Значит, нужно упростить
Распространено заблуждение, будто рефакторинг выполняется только в «моменты озарений», готовности выбросить весь старый код и создать что-то элегантное с нуля. Но рефакторинг не должен быть полной перестройкой, при мысли о которой приходишь в страх и трепет.
Цель рефакторинга — доработать код, а не сделать его идеальным. Небольшое улучшение — тоже улучшение. Например:
- Переименовать метод, чтобы оптимальнее описать, чем он занимается.
- Извлечь строки кода во вспомогательную функцию с четким наименованием.
- Переместить соответствующий кусок кода в его собственный объект.
Эти изменения простые, но важные: с ними снижается когнитивная нагрузка на следующего разработчика или на вас самих по прошествии времени, сохраняется динамика, появляется уверенность. И вот с кодом уже снова приятно работать.
Как избежать чрезмерного усложнения
При рефакторинге легко увлечься: только начинаешь извлекать логику из метода, не успеваешь оглянуться, как уже создаешь класс с кучей зависимостей, новым деревом наследования и примесями для «поддержания чистоты».
Рефакторинг — не усложнение, это удаление лишнего и повышение удобства восприятия. Как правило, при оптимальном рефакторинге код становится более понятным — четким, эксплицитным и акцентированным.
Чем глубже погружаешься в рефакторинг, тем больше соблазн перепроектировать всю архитектуру. Но прелесть рефакторинга заключается в небольших, постепенных изменениях на пути к простоте кода.
Начать с малого, сохраняя уверенность
Фокус в том, чтобы начать с крошечного изменения, при котором код не нужно неделями переписывать и тестировать. Из этих маленьких побед складываются большие. Начните с одного метода. Или с рефакторинга ненадежного теста. Главное — не усложнять и сохранять динамику.
Например, если метод занимается тремя задачами — парсингом данных, вычислением значения и сохранением его в базе данных, — не нужно разбивать его на разные классы. Выведите каждую из них в небольшую именованную вспомогательную функцию в пределах того же класса. И вот уже этот метод удобнее для восприятия — понятный и легко отслеживаемый.
Усложнение ради тщеславия
Не слушайте голос тщеславия: «Сложным решением продемонстрируешь свои навыки». Правда в том, что они демонстрируются скорее чистым кодом. Создать что-то запутанное, никому непонятное может каждый. Сделать код удобным для восприятия, изменения и сопровождения — вот реальный навык.
Поставьте перед собой задачу на ближайший рефакторинг — упростить код. Найдите способы сделать код доступнее. Оставьте его в более оптимальном состоянии, чем до того, не превращая в новый масштабный проект по перепроектированию кода.
Заключение
Рефакторинг не должен быть сложным или чем-то невозможным. Это плодотворный процесс постепенного упрощения.
Практичный подход к рефакторингу заключается в доработках без лишних сложностей, когда код и рабочий процесс преобразуются простыми и эффективными изменениями.
Не усложняйте рефакторинг, сделайте его своей привычкой, а не головной болью.
Читайте также:
- Ruby on Rails 7: важные рекомендации для высококачественного кода
- Операторы Ruby: звездочка * и двойная звездочка **
- OTP-аутентификация c Devise
Читайте нас в Telegram, VK и Дзен
Перевод статьи Tech — RubyCademy: Don’t Overcomplicate Refactoring!
