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

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


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

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

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




Необходимость рефакторинга


Грязный код


Цель рефакторинга кода - превратить грязный код в чистый и снизить общий технический долг проекта.

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

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


Некоторые типы грязного кода включают:

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




Грязный код с запахом


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

Авторы книги «Рефакторинг» Мартин Фаулер и Кент Бек дают следующие варианты запахов кода:

  • Повторяющийся код
Как следует из названия, это тот случай, когда вы оставляете один и тот же фрагмент кода в нескольких местах. Этот недочет можно исправить, извлекая код и превращая его в метод, а затем вызывая этот метод вместо копирования и вставки кода. Такое решение известно как Extract Method (метод извлечения).

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

  • Большой класс
Этот запах нарушает принцип единой ответственности (SRP); букву «S» в принципах SOLID. Этот принцип гласит, что у каждого класса должна быть только одна причина для изменения, что означает, что у него должна быть только одна ответственность. А когда у нас большой класс, это означает, что у него больше одной ответственности. Такого быть не должно, потому что из-за этого цель класса неясна. Чтобы следовать SRP, мы используем класс Extract, где один класс играет роль двух классов, или Extract Subclass, где у класса есть функции, которые используются только в некоторых экземплярах.


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


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

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