Рефакторинг программного обеспечения что это

Обновлено: 17.05.2024

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

10 месяцев назад

Мы все ищем способы очистить наш код, упростить его и улучшить функциональность. Рефакторинг открывает путь вперед.

В этом руководстве будут рассмотрены следующие темы:

Что такое рефакторинг?
Каковы преимущества рефакторинга?
Технический долг vs рефакторинг
Метрики рефакторинга
Примеры рефакторинга кода
Инструменты рефакторинга кода
Рефакторинг и вызовы для инженеров
Поддержка руководства
Командная поддержка и рефакторинг: спринт или марафон?
Документация и рефакторинг

Что такое рефакторинг?

По словам Мартина Фаулера, автора двух книг по рефакторингу:

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

Каковы преимущества рефакторинга?

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

Например, в 2014 году инженеры Kickstarter столкнулись с проблемой экспоненциального роста числа пользователей, что привело к снижению производительности запросов. В ответ они перенесли запросы MySQL на Redis и сократили типичное время загрузки более чем на 100 мс, что привело к уменьшению дисперсии времени загрузки и в целом более быстрой работе сайта.

Технический долг vs рефакторинг

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

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

Метрики рефакторинга

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

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

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

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

Существует множество примеров рефакторинга кода, но для краткости мы сосредоточимся на нескольких:

Красный, зеленый, рефакторинг

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

Красный, зеленый, рефакторинг — это пример TDD:

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

Метод извлечения (также известный как функция извлечения)

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

Извлечение переменной

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

Ветвь по абстракции

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

Составной метод

Чрезмерно длинный код трудно понять и изменить. Метод Compose относится к ряду действий, которые можно использовать для оптимизации методов и устранения дублирования кода. К ним относятся Inline Method, Inline Temp, Replace Temp with Query, разделение временных переменных и удаление назначений параметрам.

Инструменты рефакторинга кода

Вам нужны специальные инструменты для рефакторинга? Мартин Фаулер говорит, что автоматизированные инструменты полезны, но не важны. Он отмечает:

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

Многие среды разработки автоматизируют механические аспекты рефакторинга. Инструменты рефакторинга ключевого кода:

Рефакторинг и вызовы для инженеров

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

Какие задачи получают предпочтение?
Какая скорость развития?
Чувствуют ли разработчики необходимость быстрой отправки кода?
Какие существуют процессы для работы с техническим долгом?
Какие виды проверки кода предпринимаются?
Имеет ли ваша команда необходимые навыки для рефакторинга?
Каковы стандарты компании в отношении документации?

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

Поддержка рефакторинга руководством

Инвестиции в инфраструктуру и техническое обслуживание могут быть непопулярны в вашей компании.

Легко утверждать, что время, потраченное на рефакторинг, — это время, проведенное вне новой работы.

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

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

Командная поддержка и рефакторинг: спринт или марафон?

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

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

Однако он подчеркивает, что исправление плохого кода требует много времени, и придерживается более продуманного подхода, чем простое погружение в изменения:

“Мы улучшаем код, в котором работаем, и игнорируем код, с которым нам не нужно работать. Скорее всего, мы еще вернемся к нему.

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

Инженер по продукту и технический директор Андреас Клингер — поклонник Fix-it Friday.

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

Какое исправление кода окажет наибольшее влияние на ваш другой код?
Какие исправления принесут наибольшую отдачу?

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

Документация и рефакторинг

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

Документирование вашей работы по рефакторингу ведет к учету времени и предоставляет контекст для будущих членов команды.

Кроме того, задокументируйте свои успехи — каковы были самые большие выгоды от рефакторинга? Могут ли они быть учтены в экспертных обзорах?

Утопаете в коде, который требует рефакторинга и технического долга?

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

Используя XMind для краткого изложения основного содержания этой главы, вы можете видеть следующее содержимое в каждом разделе:

Общее содержание указано выше.

Определение реконструкции имеет две основные формы: форму ранжирования и форму глагола.
Форма рейтинга выглядит следующим образом:

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

Вообще говоря, рефакторинг - это небольшое изменение в программном обеспечении. Например, Extrac Class, Move Mode, Move Field.
Глаголы имеют следующую форму:

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

Две шляпы:
Рефакторинг и добавление функций, отношения между ними следующие:

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

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

4.1 Рефакторинг и улучшение дизайна программного обеспечения

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

4.2 Рефакторинг облегчает понимание программного обеспечения

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

4.3 Рефакторинг, чтобы помочь найти ошибки

Кент Бек часто описывал свои слова: Я не большой программист, я просто хороший программист с некоторыми хорошими привычками. "

4.4 Рефакторинг повышает скорость программирования

Улучшить ошибки
Улучшение читаемости
Уменьшить количество ошибок

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

4.5 Когда проводить рефакторинг

Практически в любом случае он специально выделяет время для реконструкции, и реконструкция должна проводиться в любое время и в любом месте.

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

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

Две проблемы

Что я могу сделать для тебя сегодня?
Что я могу сделать для вас завтра?

Важность косвенных слоев и рефакторинга

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

4.6 Рефакторинг и производительность

В идеях программирования на Java Брюс Экель сказал, что не стоит преждевременно фокусироваться на эффективности программы. Это привлекательная ловушка. Лучше всего сначала дать программе работать, а потом учитывать скорость.

Два выражения абсолютно одинаковы.

В случае 1 из главы 1 после удаления временных переменных вы можете увидеть функцию Statement () следующим образом:
Вы видите, что в процессе обработки функций getTotalCharge () и getTotalFrequentRenterPoints () используются две функции Replace Temp with Query,

В этом процессе используется аналогичный рефакторинг, т. Е. Так как totalAmount и ЧастоRenterPoints назначаются внутри цикла, поэтому цикл должен быть скопирован в функцию запроса во время процесса рефакторинга.

Можно видеть, что есть проблема с этим рефакторингом, а именно производительность,

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

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

Рефакторинг в курсе JavaRush

Что такое рефакторинг?

Это изменение структуры кода без изменения его функционала. Например, есть метод, который сравнивает 2 числа и возвращает true, если первое больше, и false в обратном случае: Получился очень громоздкий код. Даже новички редко пишут подобное, однако такой риск есть. Казалось бы, зачем тут блок if-else , если можно написать метод на 6 строк короче: Теперь этот метод выглядит просто и элегантно, хотя выполняет то же действие, что и пример выше. Так и работает рефакторинг: меняет структуру кода, не затрагивая его суть. Существует множество методов и техник рефакторинга, которые рассмотрим подробнее.

Для чего нужен рефакторинг?

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

“Запахи кода“

Когда код требует рефакторинга говорят, что он “пахнет”. Конечно, не буквально, но такой код действительно выглядит не совсем приятно. Ниже рассмотрим основные техники рефакторинга для начального этапа.

Неоправданно большие элементы

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

Большой класс

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

Большой метод

Если при написании метода хочется добавить комментарий в код, необходимо выделить этот функционал в отдельный метод;
Если метод занимает более 10-15 строк кода, следует определить задачи и подзадачи, которые он выполняет, и попробовать вынести подзадачи в отдельный метод.

Выделить часть функционала метода в отдельный метод;
Если локальные переменные не дают вынести часть функционала, можно передать весь объект в другой метод.

Использование множества примитивных типов данных

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

Длинный список параметров

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

Группы данных

Часто в коде появляются логически связанные группы данных. Например, параметры подключения в БД (URL, имя пользователя, пароль, имя схемы и тд). Если из перечня элементов нельзя удалить ни одно поле, значит перечень — это группа данных, которую необходимо вынести в отдельный класс (выделение класса).

Решения, которые портят концепцию ООП

“Запахи” этого типа возникают, когда разработчик нарушает дизайн ООП. Такое происходит, если он не до конца понимает возможности этой парадигмы, использует их не до конца или неправильно.

Отказ от наследования

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

Оператор switch

Что плохого может быть в операторе switch ? Он плох, когда его конструкция очень сложная. Также сюда относятся и множество вложенных блоков if .

Альтернативные классы с разными интерфейсами

Временное поле

Если в классе заложено временное поле, которое нужно объекту лишь изредка, когда он заполняется значениями, а в остальное время — пустое или, не дай бог, null , значит код “попахивает”, а такой дизайн — сомнительное решение.

Запахи, которые затрудняют модификацию

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

Параллельные иерархии наследования

Равномерное распределение зависимости

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

Сложное дерево модификаций

“Мусорные запахи”

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

Большое количество комментариев в методе

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

Дублирование кода

Ленивый класс

Неиспользуемый код

Излишняя связанность

Сторонние методы

Неуместная близость

Длинные вызовы классов

Один класс вызывает другой, тот запрашивает данные у третьего, тот у четвертого и так далее. Такая длинная цепь вызовов означает высокий уровень зависимости от текущей структуры классов.

Класс-таск-дилер

Техники рефакторинга

Ниже пойдет речь о начальных техниках рефакторинга, которые помогут устранить описанные “запахи” кода.

Выделение класса

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

Выделение метода

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

Передача всего объекта

При вызове метода с параметрами иногда можно встретить такой код: В методе employeeMethod целых 2 строки отводится на получение значений и сохранение их в примитивных переменных. Иногда такие конструкции занимают до 10 строчек. Гораздо проще передать в метод сам объект, откуда можно извлечь необходимые данные: Просто, кратко и лаконично.

Логическая группировка полей и вынос в отдельный класс

Несмотря на то, что вышеописанные примеры — очень простые и при взгляде на них многие могут задаться вопросом “Да кто вообще так делает?”, многие разработчики от невнимательности, нежелания проводить рефакторинг кода или просто “И так сойдет” допускают подобные структурные ошибки.

Почему рефакторинг эффективен

Итог хорошего рефакторинга — программа, код которой легко читать, модификации логики программы не становятся угрозой, а внесение новых фич не превращается в ад разбора кода, а приятным занятием на пару дней. Рефакторинг не стоит применять, если программу проще переписать с нуля. Например, команда оценивает трудозатраты на разбор, анализ и рефакторинг кода выше, чем на реализацию такого же функционала с нуля. Или у кода, который нужно отрефакторить, есть множество ошибок, сложных в отладке. Знание, как улучшить структуру кода обязательно в работе программиста. Ну а изучать программирование на Java лучше на JavaRush — онлайн-курсе с акцентом на практику. 1200+ задач с мгновенной проверкой, около 20 минипроектов, задачи-игры — все это поможет почувствовать себя уверенно в кодинге. Лучшее время, чтобы начать — сейчас :)

Рефакторинг (Refactoring) кода это процесс изменения исходного кода программы, не затрагивающий её поведения и ставящий целью облегчить понимание её работы и/или упростить её дальнейшую поддержку. Обычно рефакторинг любой программы это внесение небольших изменений в её код, каждое из которых не меняет само поведение программы, но как-то упрощает и/или улучшает код. При этом очень важно, что бы рефакторинг выполнялся именно небольшими частями, т.к. когда программист меняет небольшую часть кода – ему значительно проще проследить за правильностью изменений и не наделать ошибок. Если же рефакторить сразу большие участки кода, то есть очень большая вероятность наделать ошибок, в результате которых программа может вообще перестать работать. Правда, то, что правки должны быть небольшими, вовсе не означает, что рефакторинг это лишь замена имён переменных или перемещение небольших участков кода из одного места программы в другое – рефакторинг позволяет полностью переработать всю программу, включая и логику её поведения, главное при этом – вносить изменения небольшими частями и тогда всё будет в порядке.

Цели рефакторинга

Наверное, Вы спросите меня, к чему в вообще это пишу? А к тому, что, если Вы внимательно смотрите исходники примеров исходных текстов к каждому уроку – Вы, наверное, заметили, что я часто меняю что-то в коде, иногда по мелочам, а иногда довольно заметно. Это потому что я сам применяю рефакторинг и хочу, что бы и у Вас это вошло в привычку.

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

Какой код надо рефакторить

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

Когда применять рефакторинг?

На этот вопрос есть очень простой ответ: всегда. Занимайтесь рефакторингом при малейшей возможности – рефакторинг улучшает ваш код и, потратив на него сегодня 5 минут, Вы завтра сэкономите на поиске ошибок час. Самый простой метод применения рефакторинга такой: каждый раз, когда вы что-то меняете в программе – добавляете новую функцию, класс, просто объявляете переменную, или Вам надо поменять пару строк в какой-то функции – посмотрите на соседний код, находящийся выше и ниже того участка, с которым Вы работаете сейчас. Проверьте, может быть, в этот код можно внести какие-то изменения, что бы он стал ещё более понятным и/или простым, может быть Вы найдёте в нём какие-то логические ошибки или Вам в голову придёт при каком сочетании параметров код может дать сбой. Если Вы увидели что-то подобное, то займитесь рефакторингом. Но не следует скакать по коду из конца в конец – если Вы пришли что-то добавить в код или поменять – сначала сделайте то, зачем Вы пришли, а потом уже занимайтесь рефакторингом. Иначе в итоге Вы можете вообще забыть, зачем вы открыли исходник.

Когда заканчивать рефакторинг?

Постарайтесь не заболеть “синдромом рефакторинга”. Если Вы сделали код, посмотрели вокруг и всё Вас устраивает – не надо рыскать по коду в поисках “чего бы тут ещё зарефакторить”. Если Вам нечем заняться – сходите в спортзал, покатайтесь на машине, сходие в клуб или хотя бы просто попейте пивка. Делать рефакторинг только потому что Вам лень делать что-либо ещё – это очень плохая привычка.

Рефакторинг кода

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

Рефакторинг изначально не предназначен для исправления ошибок и/или добавления новой функциональности – он вообще не должен менять поведение вашей программы и именно это помогает избежать ошибок и, в будущем, облегчить добавление новой функциональности в программу. Рефаткоринг выполняется только для улучшения понятности кода и/или изменения его структуры, для удаления “мёртвого” (старого, уже не нужного, оставленного “на всякий случай”) кода – для того, чтобы в будущем код было легче поддерживать и развивать ваш код. Например, добавление в программу нового поведения может оказаться сложным с существующей структурой — в этом случае Вы можете сначала выполнить необходимый рефакторинг, а уже затем добавить новую функциональность.

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

В экстремальном программировании и других подобных гибких методологиях, рефакторинг является неотъемлемой частью цикла разработки программы: разработчики то создают новые тесты и функциональность, то выполняют рефакторинг кода для улучшения его логичности и прозрачности, и снова циклически повторяют – новые тесты/код, рефакторинг, новые тесты/код, рефакторинг и т.д. Автоматическое юнит-тестирование позволяет программистам убедиться, что рефакторинг не разрушил существующую функциональность, т.е. что он был проведён правильно и без ошибок.

Помощь в рефакторинге

Существенную помощь в рефакторинге могут оказать IDE, плагины к IDE, а так же системы контроля версий. IDE и плагины к ней, например, могут подсвечивать разработчику те строчки кода, которые он изменил с момента последней записи исходного кода на диск. Таким образом, программисту становится визуально понятно, над каким кодом он уже поработал, а какой код пока не трогал – это позволяет, при проверке “в голове” правильности написания кода, сосредоточиться на более узком фрагменте исходного кода, а не на всей программе – если даже открытый файл в длину имеет 1000 и более строк, программист с помощью IDE легко найдёт те несколько строк программы, которые он только что поменял, даже если они находятся в разных концах исходного текста.

Системы контроля (а точнее оболочки для них) версий при этом позволяют программисту, помимо всего прочего, сравнивать его текущий код с предыдущими версиями этого же кода. Чаще всего они даже могут визуально оформить различия между текущим и прошлыми исходниками – например, подсветить новый код зелёным, удалённый код нарисовать красный и/или зачёркнутым, посмотреть всю историю развития кода, прочитать комментарии, которые делались при заливке апдейтов исходников в систему контроля версий и многое другое. В общем, эти системы очень удобная штука и они могут помочь в том числе и при проведении рефакторинга.

Вместо заключения или как научиться рефакторингу

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

Возможно, Вам первое время будет казаться, что рефакторинг занимает слишком уж много времени и сил, и что именно он не позволяет Вам найти время на дальнейшее развитие вашей программы. Однако, это мнение ошибочно – на самом деле, рефакторинг наоборот, ускоряет развитие программы, т.к. со временем Вы всё больше и больше экономите времени на том, что отрефакторенный код будет для Вас же самих намного понятнее, удобнее, он будет содержать в разы меньше ошибок и, в итоге, на одних только исчезнувших ошибках или недочётках кода (которые могли бы потом привести к ошибкам), Вы будете экономить огромное количество времени. Кстати, этот факт подтверждён исследованиями таких больших и уважаемых компаний, как IBM, HP, Microsoft, Sony и многих других.

Читайте также: