Что такое рефакторинг кода и зачем он нужен / Skillbox Media

#статьи

• 6 окт 2020

• 12

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

Vkontakte

Twitter

Telegram

Скопировать ссылку

 vlada_maestro / shutterstock

Марина Демидова

Программист, консультант, специалист по документированию. Легко и доступно рассказывает о сложных вещах в программировании и дизайне.

Рефакторинг — это переработка исходного кода программы, чтобы он стал более простым и понятным.

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

Например, вот фрагмент на Python, создающий список из строки:

list = []
for char in 'abcdef':
 if char != 'c':
	list.append(char * 2)
print(list) # ['aa','bb','dd','ee','ff']

При рефакторинге его можно упростить, применив конструктор списков:

list = [char * 2 for char in 'abcdef' if char != 'i']
print (list)

Результат работы программы не изменился, но код стал проще, компактнее и понятнее.

Последовательность таких небольших изменений может сильно улучшить качество проекта.

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

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

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

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

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

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

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

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

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

После рефакторинга программа может начать работать быстрее, но главное — её код становится проще и понятнее.

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

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

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

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

Рефакторинг — это маленькие последовательные улучшения кода. Чистить можно всё, но в первую очередь найдите эти проблемы:

1. Мёртвый код. Переменная, параметр, метод или класс больше не используются: требования к программе изменились, но код не почистили. Мёртвый код может встретиться и в сложной условной конструкции, где какая-то ветка никогда не исполняется из-за ошибки или изменения требований. Такие элементы или участки текста нужно удалить.
2. Дублирование. Один и тот же код выполняет одно и то же действие в нескольких местах программы. Вынесите эту часть в отдельную функцию.
3. Имена переменных, функций или классов не передают их назначение. Имена должны сообщать, почему элемент кода существует, что он делает и как используется. Если видите, что намерения программиста непонятны без комментария, — рефакторьте.

   Примеры корректных имен: totalScore — переменная, означающая итоговый счёт в игре, maxWeight — максимальный вес. Для функций и методов лучше использовать глаголы, например: saveScore () — сохранить счет, setSize () — задать размер, getSpeed () — получить скорость.

4. Слишком длинные функции и методы. Оптимальный размер этих элементов — 2-3 десятка строк. Если получается больше, разделите функцию на несколько маленьких и добавьте одну общую. Пусть маленькие выполняют по одной операции, а общая функция их вызывает.
5. Слишком длинные классы. То же самое. Оптимальная длина класса — 20–30 строк. Разбейте длинный класс на несколько маленьких и включите их объекты в один общий класс.
6. Слишком длинный список параметров функции или метода. Они только запутывают, а не помогают. Если все эти параметры действительно нужны, вынесите их в отдельную структуру или класс с понятным именем, а в функцию передайте ссылку на него.
7. Много комментариев. Плохой код часто прикрывается обильными комментариями. Если почувствовали желание пояснить какой-то участок кода, попробуйте сначала его переписать, чтобы и так стал понятным. Бесполезные комментарии загромождают программу, а устаревшие и неактуальные вводят в заблуждение.

После каждой правки посмотрите на соседние участки кода: возможно, их тоже стоит поправить и сделать понятнее. И на те участки кода, которые давно не редактировались, — они уже могли стать некорректными.

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

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

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

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

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

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

Рефакторьте постоянно и по чуть-чуть.

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

Но всё равно нельзя пренебрегать усовершенствованием кода, потому что это лучший способ ускорить работу в будущем.

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

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

Vkontakte

Twitter

Telegram

Скопировать ссылку

«Сбер» представил конкурента ChatGPT под названием GigaChat
24 апр 2023

Российские учёные научились предсказывать феномен Эль‑Ниньо с помощью нейросети
24 апр 2023

Adobe добавит нейронку для работы с видео в Premiere Pro и After Effects
19 апр 2023

Понравилась статья?

Да

что это такое, зачем он нужен, методики и риски переработки исходного кода

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

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

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

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

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

Что не является рефакторингом

Определение рефакторинга сильно размыто. Иногда так называют процессы, которые связаны с изменением структуры кода, но по сути им не являются. Рассмотрим примеры.

Дебаггинг

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

Улучшение функциональности ПО

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

Оптимизация

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

Рефакторинг и проектирование

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

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

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

Когда без рефакторинга не обойтись

Плановый рефакторинг

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

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

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

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

По мере необходимости *

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

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

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

Проблемы, которые решит рефакторинг

Существует множество проблем, которые указывают на то, что нужен рефакторинг. Ниже перечислены некоторые из них.

Мертвый код

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

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

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

Повторяющийся код

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

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

Имя элемента кода не отражает его значение

Еще одна проблема, которая распространена у новичков: название элемента или объекта не отражает его значения. Например, переменная имеет очень общее название или однобуквенное обозначение. Это сильно усложняет читаемость кода, а следовательно, и его дальнейшую поддержку.

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

...
def new_item(self, a):
   if self.b.n + 1 <= self.b.mn and self.b.w + a.w < self.b.mw:
       self.b.new_item(a)
...

После рефакторинга

...
def add_item_to_backpack(self, item):
   has_place_ = self.backpack_.n_items_ + 1 <= self.backpack_.max_n_items_
   can_carry_ = self.backpack_.weight_ + item.weight < self.backpack_.max_weight_
   if has_place_ and can_carry_:
       self.backpack_.add_new_item(item)
...

Обратите внимание на пример. Думаю, что все согласятся: во втором случае код более понятный.

Чрезмерно длинные методы

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

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

Слишком длинные классы

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

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

Избыточное количество комментариев

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

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

Проектирование впрок

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

В книге «Совершенный код» Стива Макконнелла это называется «проектирование впрок». Автор приводит мнение экспертов, которые однозначно заявляют, что гораздо лучше написать простой и понятный код, который нужен здесь и сейчас.

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

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

Red-Green-Refactor

Одной из популярных методик рефакторинга является Red-Green-Refactor. Написание программы происходит в три этапа:

1. Red. Написание тестов, выполнение которых позволит говорить, что задача была решена.
2. Green. Написание минимального кода, который позволит пройти тесты и решить поставленную задачу.
3. Refactor. Рефакторинг — разработчики выстраивают структуру кода и удаляют ненужные участки.

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

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

Визуализация методики Red-Green-Refactor

Абстракция

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

Рассмотрим на примере кода из компьютерной игры. В первом случае у разработчика есть два класса — Warrior и Archer, — у которых повторяются свойства name и heath_points. Тогда разработчик создаст новый класс Unit, в который унесет свойства name и heath_points, а специфичные методы has_shield и n_arrows оставит в изначальных классах.

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

class Warrior():
...
    @property
    def name(self):
        return self._my_name

    @property
    def heath_points(self):
        return self._hp

    @has_shield.setter
    def has_shield(self, shield):
	  if shield and not self._has_shield:
	     self._has_shield = True
	  ...
...

class Archer():
...
    @property
    def name(self):
        return self._my_name

    @property
    def heath_points(self):
        return self._hp

    @n_arrows.setter
    def n_arrows(self, number):
        if number < self._max_arrows:
	      self._n_arrows = number
...

После рефакторинга

class Unit():
...
    @property
    def name(self):
        return self._my_name

    @property
    def heath_points(self):
        return self. _hp
... 

class Warrior(Unit):
...
    @has_shield.setter
    def has_shield(self, shield):
	  if shield and not self._has_shield:
		self._has_shield = True
	  ...
...

class Archer(Unit):
...
    @n_arrows.setter
    def n_arrows(self, number):
	  if number < self._max_arrows:
		self._n_arrows = number
...

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

Фрагментация методов

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

Есть много техник, чтобы достичь результата. Рассмотрим несколько из них на примере игры из предыдущего пункта:

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

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

class Unit():
...
    def go_forward_and_left(self, steps):
        self.coordinates.y += steps
        self.coordinates.x -= steps
...

После рефакторинга

class Unit():
...
    def go_forward(self, steps):
        self.coordinates.y += steps

    def go_left(self, steps):
        self.coordinates.x -= steps
...

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

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

class Archer(Unit):
...
    def attack(self, enemy):
        if (not self.has_bow or self.n_arrows < 1 or \\
            Unit.distance(enemy) > 5.0 or \\
            Unit.distance(enemy) < 1.0) and \\
            (not self.has_dagger or Unit.distance(enemy) > 1.0):
            # do not attack
        . ..
...

После рефакторинга

class Archer(Unit):
...
    def attack(self, enemy):
        can_shoot = self.has_bow and self.n_arrows > 0
        in_shoot_range = Unit.distance(enemy) <= 5.0 and \\
                         Unit.distance(enemy) > 1.0
        can_use_dagger = self.has_dagger and \\
				  Unit.distance(enemy) <= 1.0

        if not (can_shoot and in_shoot_range) and not can_use_dagger:
           # do not attack
        ...
...

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

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

Есть простые правила, которые позволят минимизировать риски что-либо сломать. Очень полезно сохранять исходный код перед исправлениями или пользоваться системой контроля версий.

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

Вебинары

Коротко о главном

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

Выше мы рассмотрели некоторые практики, которые полезны и эффективны в работе любого разработчика. Чтобы глубже погрузиться в тему рефакторинга, можно изучить книги Мартина Фаулера «Рефакторинг. Улучшение существующего кода» и «Совершенный код» Стива Макконнелла (глава 24 — «Рефакторинг»).

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

Архитектура приложения

К

• Александр С. Гиллис,
  Технический писатель и редактор

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

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

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

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

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

Какова цель рефакторинга?

Рефакторинг улучшает код, делая его:

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

Модификация кода производится без изменения каких-либо функций самой программы. Многие базовые среды редактирования поддерживают простой рефакторинг, например переименование функции или переменной во всей кодовой базе.

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

Когда следует рефакторить код?

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

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

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

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

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

Рефакторинг может дать следующие преимущества:

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

Каковы проблемы рефакторинга?

Однако в процессе возникают трудности. Некоторые из них включают:

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

Методы выполнения рефакторинга кода

Организации могут использовать разные методы рефакторинга в разных случаях. Некоторые примеры включают:

• Красный, зеленый. Этот широко используемый метод рефакторинга в Agile-разработке включает три этапа. Во-первых, разработчики определяют, что необходимо разработать; во-вторых, они проходят тестирование своего проекта; и в-третьих, они рефакторят этот код, чтобы внести улучшения.
• Встроенный. Этот метод направлен на упрощение кода за счет исключения ненужных элементов.
• Перемещение объектов между объектами. Этот метод создает новые классы, перемещая функциональные возможности между новыми и старыми классами данных.
• Экстракт. Этот метод разбивает код на более мелкие части, а затем перемещает эти части в другой метод. Фрагментированный код заменяется вызовом нового метода.
• Рефакторинг путем абстракции. Этот метод уменьшает количество повторяющегося кода. Это делается, когда требуется рефакторинг большого количества кода.
• Составление. Этот метод оптимизирует код для уменьшения дублирования с помощью нескольких методов рефакторинга, включая извлечение и встроенный код.

Лучшие практики рефакторинга кода

Рекомендации по рефакторингу:

• План рефакторинга. В противном случае может быть трудно найти время для отнимающей много времени практики.
• Рефакторинг сначала. Разработчики должны сделать это перед добавлением обновлений или новых функций в существующий код, чтобы уменьшить технический долг.
• Рефакторинг небольшими шагами. Это дает разработчикам обратную связь на ранних стадиях процесса, чтобы они могли найти возможные ошибки, а также включить бизнес-запросы.
• Ставьте перед собой четкие цели. Разработчики должны определить объем и цели проекта на ранней стадии процесса рефакторинга кода. Это помогает избежать задержек и дополнительной работы, поскольку рефакторинг должен быть формой домашнего хозяйства, а не возможностью изменить функции или функции.
• Проверяйте часто. Это помогает гарантировать, что рефакторинговые изменения не приведут к появлению новых ошибок.
• Автоматизируйте везде, где это возможно. Средства автоматизации упрощают и ускоряют рефакторинг, тем самым повышая эффективность.
• Исправить программные дефекты отдельно. Рефакторинг не предназначен для устранения недостатков программного обеспечения. Устранение неполадок и отладку следует выполнять отдельно.
• Разобраться с кодом. Просмотрите код, чтобы понять его процессы, методы, объекты, переменные и другие элементы.
• Рефакторинг, исправление и регулярное обновление. Рефакторинг приносит наибольшую отдачу от инвестиций, когда он может решить важную проблему, не требуя слишком много времени и усилий.
• Сосредоточьтесь на дедупликации кода. Дублирование усложняет код, увеличивая объем программного обеспечения и расходуя системные ресурсы.

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

Последнее обновление: сентябрь 2021 г.

Продолжить чтение О рефакторинге

• Часто задаваемые вопросы по основам Agile: Начало работы с Agile

• Рефакторинг или переписывание: решение, что делать с проблемным программным обеспечением

• Ключевые аспекты рефакторинга приложений для облака

• Основы рефакторинга монолита в микросервисы

• Почему вам следует рефакторить, а не переписывать ваш код

Копните глубже в разработку и проектирование приложений

• 5 способов справиться с проблемами монолитных архитектур

  Автор: Крис Тоцци

• Главный операционный директор Sourcery: давайте сделаем рефакторинг кода постоянным

  Автор: Адриан Бриджуотер

• Понимание запахов кода и как рефакторинг может помочь

  Автор: Джойдип Канджилал

• Как управлять техническим долгом и сокращать его в Agile

  Автор: Джойдип Канджилал

Качество ПО

• 
  Как создать набор регрессионных тестов

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

• 
  Как сбалансировать доступ к данным и безопасность в финтех-тестировании

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

• 
  Тестовые фреймворки и примеры для модульного тестирования кода Python

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

Облачные вычисления

• 
  Преимущества и ограничения Google Cloud Recommender

  Расходы на облако могут выйти из-под контроля, но такие службы, как Google Cloud Recommender, предоставляют информацию для оптимизации ваших рабочих нагрузок. Но…

• 
  Zadara выбирает нового генерального директора, поскольку основатель переходит на роль технического директора

  Йорам Новик, второй генеральный директор облачного стартапа Zadara, привносит в эту должность многолетний опыт руководства ИТ и рассказывает о …

• 
  Как работает маршрутизация на основе задержки в Amazon Route 53

  Если вы рассматриваете Amazon Route 53 как способ уменьшить задержку, вот как работает этот сервис.

TheServerSide.com

• 
  Как избежать выгорания удаленного инженера-программиста

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

• 
  JavaScript против TypeScript: в чем разница?

  TypeScript и JavaScript — две дополняющие друг друга технологии, которые стимулируют разработку как интерфейсных, так и серверных приложений. Вот…

• 
  Как применить принцип единой ответственности в Java

  Как работает модель единой ответственности в программе Java? Здесь мы покажем вам, что означает этот принцип SOLID, и как …

Рекомендации по рефакторингу кода: когда (и когда нет) делать это

Время чтения: 7 минут

Это гостевая история Сидни Стоуна, писателя из компании по разработке программного обеспечения iTechArt.

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

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

Вот почему необходим рутинный рефакторинг кода.

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

Когда следует задуматься о рефакторинге программного обеспечения?

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

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

Как проводить рефакторинг кода: основные приемы

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

При этом существует множество различных подходов и методов рефакторинга кода. Некоторые из самых популярных:

Red-Green-Refactor

Одним из наиболее широко используемых методов рефакторинга кода является красный/зеленый процесс, используемый в Agile-разработке через тестирование. Применяя метод Red-Green-Refactor, разработчики разбивают рефакторинг на три отдельных этапа:

1.   Остановитесь и подумайте, что нужно разработать. [КРАСНЫЙ]
2.   Проведите базовое тестирование разработки. [ЗЕЛЕНЫЙ]
3.   Внести улучшения. [РЕФАКТОР]

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

Рефакторинг с помощью абстракции

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

Одним из примеров абстракции является метод Pull-Up/Push-Down . Это две противоположные формы рефакторинга с участием классов. Метод Pull-Up извлекает части кода в суперкласс, чтобы исключить дублирование кода. Push-Down берет его из суперкласса и перемещает в подклассы.

Метод Pull-Up/Push-Down

Метод компоновки

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

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

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

Упрощение методов

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

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

Перемещение функций между объектами

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

Подготовительный рефакторинг

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

Разработчик программного обеспечения Джессика Керр дает отличное наглядное объяснение подготовительного рефакторинга:

«Это как будто я хочу проехать 100 миль на восток, но вместо того, чтобы просто бродить по лесу, я собираюсь проехать 20 миль на север до шоссе и затем я поеду на 100 миль на восток со скоростью, в три раза превышающей скорость, которую я мог бы иметь, если бы просто поехал прямо туда. Когда люди подталкивают вас просто идти прямо туда, иногда вам нужно сказать: «Подождите, мне нужно проверить карту и найти кратчайший маршрут». Подготовительный рефакторинг делает это за меня».

Подготовительный рефакторинг

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

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

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

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

Рекомендации по рефакторингу кода

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

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

Вот несколько других передовых практик:

Рефакторинг перед добавлением каких-либо новых функций

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

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

Тщательно спланируйте проект и график рефакторинга

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

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

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

Тестировать часто

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

Перед началом любого проекта рефакторинга убедитесь, что у вас есть необходимые тесты.

Вовлеките свою команду контроля качества

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

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

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

Сосредоточьтесь на прогрессе, а не на совершенстве

Весь код в конечном итоге становится ужасным устаревшим кодом.

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

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

Попробуйте автоматизировать рефакторинг

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

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

Две IDE (интегрированные среды разработки), которые имеют встроенную поддержку автоматизированного рефакторинга, — это Eclipse и IntelliJ IDEA. Ищите в ближайшем будущем больше автоматизации рефакторинга в других IDE, так как ярлыки рефакторинга продолжают вызывать серьезную озабоченность у сообщества разработчиков.

Заключение

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

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

This entry was posted in Популярное