Что такое рефакторинг кода и когда он нужен

Зачем нужен рефакторинг

Мартин Фаулер, американский программист и автор книги «Refactoring: Improving the Design of Existing Code», определяет рефакторинг как совершенствование структуры существующего кода через внесение правок, каждая из которых «слишком маленькая, чтобы тратить на нее время», но в совокупности они ощутимо облегчают разработку и при этом не меняют внешнее поведение приложения. Рефакторинг можно сравнить с уборкой рабочего места. Как стол со временем захламляется бумагами, справочной литературой, кружками, записками и прочими вещами, в которых нужно рыться, чтобы найти необходимое, — так и программный код постепенно наполняется бесполезными строками, поясняющими комментариями, которые можно опустить, повторяющимися и сложно названными элементами. Это происходит из-за гибкости самого процесса ИТ-разработки. Требования к задаче могут меняться в ходе ее выполнения, находятся баги во время тестирования, начальство подгоняет специалистов, чтобы проект был завершен вовремя, появляются срочные доработки, которые нужно внести. Все это в результате сказывается на структурированности кода: он становится хаотичным, замусоренным, «раздутым». А если старый код сложен и неудобен для чтения, то написать новый тоже будет непросто.

Периодически удаляя и исправляя проблемные части в этом хаосе, разработчик совершенствует код и создает для себя (и других) комфортные рабочие условия. Проще говоря, цель рефакторинга — привести код программы к удобоваримому виду, придать ему лаконичную и стройную форму, чтобы любой кодер мог разобраться в том, как он устроен. Процедуру рефакторинга нужно проводить регулярно и «по чуть-чуть», иначе есть риск навечно завязнуть в коде, пытаясь улучшить все и сразу.

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

Чем рефакторинг отличается от оптимизации

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

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

Простыми словами, оптимизация — это улучшение производительности и повышение скорости работы, рефакторинг же влияет на понятность кода, визуальную картинку. После рефакторинга программное обеспечение не всегда начинает функционировать быстрее — иногда оно даже замедляется. Главное — сделать код чище и логичнее.

В каких случаях нужен рефакторинг

Если кратко, рефакторингу необходимо уделять внимание на протяжении всего процесса разработки. Не нужно дожидаться особого момента, когда без упрощения кода работа станет невозможна.

Тем не менее существует несколько признаков, свидетельствующих о необходимости срочного рефакторинга:

• доработка ПО отнимает у разработчиков неоправданно много времени из-за трудности интегрирования новых возможностей в старый код;
• устранение ошибок требует долгого выяснения причин, по которым они возникли, долгого поиска проблемных участков кода;
• программисты в команде не могут разобраться в кодовых дебрях и приходится объяснять даже, казалось бы, очевидные вещи;
• требуется вносить одинаковые изменения в разные части кода.

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

Когда не стоит заниматься рефакторингом кода

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

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

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

Правила и методики рефакторинга

Как мы уже сказали, рефакторинг предполагает лишь перестраивание исходного кода, а не создание нового. Главный принцип — упростить структуру, не меняя поведения. Для этого важно соблюдать несколько правил.

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

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

В-третьих, рефакторингами нужно облегчать работу людям, а не компьютерам. Делайте код человекопонятным и компактным.

Ритм рефакторинга должен выглядеть следующим образом: тест — мелкая правка — тест — мелкая правка. Только так можно надежно отредактировать код. Для достижения этой цели программисты используют самые разные техники. Методы рефакторинга включают в себя множество практик и стратегий, которые в основном привязаны к изменяемому компоненту (функции, методу, объекту).

В первую очередь при «чистке» кода следует:

• удалять «мертвый код», т. е. элементы, которые больше не используются;
• выносить в отдельную функцию одинаковые фрагменты, чтобы устранить дублирование;
• переименовывать переменные, классы и функции, если нынешние названия не сообщают об их назначении;
• дробить слишком длинные (свыше трех десятков строк) компоненты на более мелкие;
• удалять бесполезные комментарии.

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

Заключение

Рефакторинг — это процесс улучшения кода с визуальной и логической точек зрения. Его глобальная цель заключается в упрощении дальнейшей работы с программным продуктом для разработчиков. Рефакторить код необходимо периодически, а не как «припрет». Если не ввести эту процедуру в привычку, рано или поздно код превратится в непроходимые дебри, так что ни другие программисты, ни вы сами не сможете разобраться, что и к чему относится. Иногда refactoring используют как отговорку, если не хотят браться за выполнение важных и сложных задач, но, честно говоря, он почти никогда не бывает лишним. Главное, уметь видеть потенциальные проблемы, к которым может привести пренебрежение рефакторингом, и вовремя применять его для их избежания.

Автор: Макхост