Здравствуйте, в этой статье мы постараемся ответить на вопрос: «Что такое рефакторинг кода и зачем он нужен». Если у Вас нет времени на чтение или статья не полностью решает Вашу проблему, можете получить онлайн консультацию квалифицированного юриста в форме ниже.
Есть гласное правило для всех программистов – код должен быть лаконичным, хорошо структурированным и понятным для разработчиков, работающих с ним. Проблема в том, что написать такой код с первого раза – очень сложная задача. Каким бы опытным ни был программист, начальство заставит его спешить, заказчики будут менять требования по ходу разработки, а иногда код будет становиться непонятным из-за банального недосыпа. Более того, сами языки программирования регулярно совершенствуются и обретают новые возможности, позволяя заметно сократить количество кода. Поэтому и нужен рефакторинг.
В каких случаях нужен рефакторинг?
Есть ряд ситуаций, которые «кричат» о необходимости рефакторинга:
-
Попытка внести любое улучшение или добавление новой функции в приложение превращается в проблему для разработчиков, а сроки выполнения, на первый взгляд, несложных операций затягиваются на неадекватный срок из-за того, что база кода напоминает дебри.
-
Сроки добавления новых функций в приложение на постоянной основе становятся размытыми, потому что разработчикам приходится закладывать время на анализ кода.
-
Приходится выполнять идентичные процедуры в разных участках кода (объектах, классах) вместо того, чтобы внести изменение в одном классе, и оно возымело бы эффект в других участках ПО.
-
Код не соответствует общепризнанным в компании практикам оформления, из-за чего не может использоваться для дальнейшей разработки с учетом ранее установленных требований.
Рефакторинг и проектирование
Рефакторинг — дорогой для бизнеса процесс. Программисты получают зарплату, но не добавляют новых функций и не ускоряют код. Вместо этого они переписывают уже существующий. Данный процесс зачастую необходим и может сохранить много времени и денег в будущем, но возможно ли убрать полностью или сократить время, которое тратится на рефакторинг? Ответ: да, можно.
Еще до написания нужно подумать об архитектуре будущего кода. Часто перед тем, как начать писать программу, программисты проектируют ее структуру. Это сильно помогает в создании качественного кода и позволяет тратить меньше времени на его рефакторинг в дальнейшем.
Кроме того, проще думать над структурой программы, когда она находится в разработке, чем в тот момент, когда она уже работает и участвует в бизнес-процессах.
Правила и методика рефакторинга
- Подготовить тесты до начала процедуры чистки кода и обращаться к ним после каждого, даже самого маленького, изменения. Самая лучшая схема: небольшое изменение — тест — небольшое изменение — тест.
- Не браться за изменение всего и сразу, править небольшие фрагменты. При редактировании больших кусков или всего сразу можно запутаться в изменениях, допустить ошибку и потратить кучу времени на ее поиск.
- Код должен быть понятен не только компьютеру, но и человеку. Не стоит вносить изменения, которые отрицательно отразятся на читаемости и усложнят поддержку работоспособности.
- Не вносить доработок и не дебажить во время рефакторинга. Велик шанс не найти потом концов.
- Бэкапы и еще раз бэкапы. Любое изменение кода должно подразумевать возможность откатиться назад без потери большого количества данных.
Оценка эффективности рефакторинга
Анализ и рефакторинг сделан успешно, если в результате вы имеете чистый, простой и понятный код.
К примеру, если количество покупателей в программе обозначено буквой Z, то лучше вместо неё поставить customerCount. Так код будет выглядеть яснее, и выполняемые в нём операции – тоже.
Если какая-то часть кода повторяется два раза и более, то есть смысл задать её в виде функции или метода. Тогда эти повторяющиеся фрагменты не нужно будет выискивать по всему коду, понадобится сделать замену лишь в одном месте.
Размеры функций, методов и классов тоже имеют значения. Если функция не влезает целиком в экран, то её нужно разбить на две части, тогда код будет легче читаться.
Еще один способ упростить код – все функции собрать в самостоятельный файл, а потом уже ввести его в программу.
Лучшие практики эффективного рефакторинга кода
Чтобы обеспечить успешный и эффективный рефакторинг, крайне важно следовать некоторым лучшим практикам. Вот несколько рекомендаций по эффективному рефакторингу кода:
- Проводите регулярные проверки кода: проверки кода помогают командам определить области кодовой базы, которые требуют рефакторинга и потенциально могут уменьшить избыточность кода и улучшить удобство обслуживания.
- Используйте системы контроля версий. Используйте системы контроля версий, такие как Git, для отслеживания изменений кода во время рефакторинга. Это позволяет вам вернуться к предыдущим версиям кодовой базы, если что-то пойдет не так, или отслеживать эволюцию кода с течением времени.
- Создайте четкий план и цель. Имейте четко определенную цель и план процесса рефакторинга. Это помогает сделать процесс рефакторинга целенаправленным, эффективным и согласованным с требованиями вашего проекта.
- Внедряйте автоматизированные тесты. Автоматизированные тесты гарантируют, что ваш рефакторинг кода работает должным образом, и помогают обнаружить любые нежелательные изменения в функциональности. Обязательно охватывайте различные случаи, а написание тестов перед рефакторингом может послужить подстраховкой.
- Вносите небольшие, постепенные изменения. Вместо одновременного внесения значительных изменений в кодовую базу выбирайте небольшие, постепенные изменения. Это сводит к минимуму риски и позволяет более эффективно оценить влияние ваших усилий по рефакторингу.
- Общайтесь со своей командой: убедитесь, что ваша команда осведомлена о планах и ходе рефакторинга. Сотрудничество и обсуждение процесса рефакторинга помогает добиться лучших результатов и предотвратить возникновение потенциальных проблем.
Следование этим передовым практикам может помочь сделать процесс рефакторинга более систематическим, эффективным и успешным.
Как договориться с коллегами?
Может оказаться, что менеджеру не понравится, что вы ковыряетесь в старом коде вместо того, чтобы делать новый. А может быть, и коллегам не понравится, что вы трогаете старый код с риском сломать его — особенно если это их код.
Что ж, самое простое тут — это менеджер. Рефакторинг — способ двигаться быстрее, так что можно попробовать зайти с экономической стороны вопроса. Но, в целом, можете просто ничего про рефакторинг не рассказывать, не его это дело. Фича готова? Готова. А как именно — это уже детали реализации. Самое главное — помнить, что вы профессионал и вам лучше видно, как делать свою работу.
Если против вас ополчилась команда и договориться не удалось никак, то тут все плохо. Обычно такие глубокие разногласия приводят к разводам — кто-то уходит, а кто-то остается. Вопрос лишь в том, кто у руля.
На этом мы, пожалуй, и закончим знакомство с НАСТОЯЩИМ рефакторингом.
И теперь у вас уже достаточно инструментов, чтобы безопасно и качественно приводить свою кодовую базу в порядок.
Для проекта «Личный кабинет студента РЭА им. Г.В. Плеханова» мы провели рефакторинг импорта данных из 1С на сайт. Всего импортируется 16 разных сущностей. До рефакторинга был реализован последовательный импорт. Это значит, что пока в обработке находился один файл импорта, остальные файлы не импортировались. Все это приводило к задержке в обработке данных.
После проведения рефакторинга каждая импортируемая сущность запускается отдельными cron-задачами. Кроме того, была сделана разбивка импорта на параллельные потоки с гибкой настройкой их количества для одной сущности.
Благодаря этому скорость обработки импортируемых данных увеличилась в 3 раза.
Таким образом мы не просто улучшили читаемость кода, но и изменили поведение системы: сделали ее более оптимальной в отдельно взятых блоках функциональностей.
Декомпозиция рефакторинга
Как и для пользовательских историй, разбиение на подзадачи важно и для рефакторинга, так как это помогает поддерживать постоянный поток процесса разработки. В Таблице 1 представлены некоторые полезные методы для декомпозиции задач по рефакторингу и пример по каждому из них.
| 1. По пользовательским сценариям или пользовательским историям — рефакторить инкрементально историю за историей, или сценарий за сценарием, или каким-то иным способом выделить несколько функциональных областей для их последовательного рефакторинга. | |
| Оптимизировать запросы к БД и внедрить кеширование данных, чтобы система работала быстрее | …Отрефакторить все функции управления пользователями… Далее функционал просмотра каталога… Далее функционал проверки работоспобности |
| 2. По компонентам — сначала провести рефакторинг кода одного компонента, а потом перейти к следующему. | |
| Поменять процесс индексирования на пакетную обработку, чтобы процесс был как минимум в 2–3 раза быстрее для средней веб-страницы | …Рефакторим парсинг (компонент парсера)… Далее экстрактор сущностей (компонент-анализатор)… Далее хранение в индексе (компонент индекса) |
| 3. По интерфейсам/реализациям — сначала создаем интерфейс и оборачиваем им старую функциональность, а потом рефакторим саму функциональность. | |
| Извлечь все параметры синтаксического анализа в xml-файл конфигурации, чтобы процесс можно было легко настроить без изменения кода | …Ставим PINGID Protocol server и тестим его с помощью провайдера идентификации mock…Читаем конфигурацию из файла в любом формате… Рефакторим функциональность конфигурирования, чтобы поддерживать в должном состоянии валидацию структуры и схемы |
| 4. Уменьшение устаревшего кода / Разделение монолита — постепенно переносим функциональность из legacy-компонента (компонент с устаревшим кодом) в новые; как только все будет перемещено, удаляем старый код. | |
| Заменить базу данных пользовательским поисковым индексом, чтобы производительность индексирования и поиска повысилась в 10-20 раз | …Сначала переносим индексацию данных в поисковый индекс… Далее переносим словари |
| 5. Точечный рефакторинг / Инкапсуляция результата – сначала рефакторим там, где это нужно, но потом извлекаем измененную сущность и инкапсулируем ее в компонент, класс или метод/функцию. | |
| Заменить ad hoc синтаксический анализ на анализ на основе грамматики так, чтобы изменение правил синтаксического анализа стало простым и без необходимости кодирования | …Рефакторим текущий код так, чтобы он использовал нотацию грамматик… Извлекаем эту функциональность и помещаем ее в движок грамматик |
Важные моменты при рефакторинге
Как понять, был ли рефакторинг успешным? Да, если в результате код стал более чистым, простым и понятным.
К примеру, если переменная А отвечает за число покупателей, то желательно назвать ее customerCount – это облегчит понимание кода.
Если фрагмен используется несколько раз, его стоит оформить, как отдельную функцию/метод. Так будет проще в дальнейшем вносить изменения – обновить одно место, а не искать одинаковые фрагменты по всем строкам.
Для лучшей читаемости кода большие функции, которые не помещаются целиком на экране, разбивают на несколько менее объемных. Иногда часть функций вообще переносят в отдельный файл, а затем присоединяют его к коду.
Нужно понимать, что рефакторинг – это не синоним оптимизации. Его цель – сделать код понятнее, а оптимизация нужна для ускорения и улучшения эффективности программы.
Когда его нужно проводить, а когда нет
Учитывая то, что на оптимизацию требуются силы и время, важно четко понимать целесообразность проведения рефакторинга. Явными признаками того, что code нужно корректировать, являются:
-
Неудачные попытки расширения функционала или внесения каких-либо улучшений – даже простые вроде бы операции затягиваются по времени из-за сложности кода
-
Многократное проведение одинаковых процедур на разных классах или объектах вместо коррекции одного участка, который бы «подтянул» за собой остальные
-
Проблемы с прогнозированием затрат времени на добавление новых опций из-за необходимости проведения детального анализа кода, напоминающего дебри
-
Несоответствие кода установленным в организации стандартам оформления, что блокирует последующую разработку с учетом стартовых требований заказчика
-
Неправильное число пробелов вначале строки
Как видите, большое значение имеют принципы работы в конкретной компании.
Правила проведения рефакторинга
Еще до переработки нужно определиться со следующими моментами:
-
Предпочтительными задачами
-
Темпами развития
-
Существованием реальной потребности в оптимизации
-
Уже используемыми инструментами работы с техническим долгом
-
Ранее предпринятыми проверками
-
Наличием навыков для внесения изменений в code
-
Действующими в компании стандартами оформления документации
-
Кодами, которые больше остальных ухудшают производительность
-
Методами исправления, способными обеспечить максимальную отдачу
Рефакторинг и вызовы для инженеров
Чтобы решить проблемы, которые привели к необходимости рефакторинга, необходимо изучить, как работает ваша компания. Прежде чем начать процесс рефакторинга, ответьте на несколько вопросов:
- Какие задачи получают предпочтение?
- Какая скорость развития?
- Чувствуют ли разработчики необходимость быстрой отправки кода?
- Какие существуют процессы для работы с техническим долгом?
- Какие виды проверки кода предпринимаются?
- Имеет ли ваша команда необходимые навыки для рефакторинга?
- Каковы стандарты компании в отношении документации?
Без решения основных проблем, вызывающих необходимость в рефакторинге, проблема будет только разрастаться.
Какой код надо рефакторить
Рефакторить можно и, часто, нужно, любой код – чаще всего надо просто полагаться на своё чутьё, если какой-то код кажется Вам не очень удачным или Вам кажется, что через неделю Вы уже забудете что делает тот или иной участок кода – скорее всего, этому коду требуется рефакторинг. Я попробую сформулировать основные правила, основываясь на которых, Вы можете понять, что ваш код требует переработки:
-
Если в вашей программе есть дублирование кода, то почти наверняка требуется рефакторинг. Дублирующийся код в программе – основной источник ошибок. Если в вашей программе какое-то действие выполняется в нескольких разных местах, но одним и тем же кодом – просто вынесите этот код в отдельную функцию и вызывайте её. Иначе высока вероятность того, что однажды Вы отредактируете исходник в одном месте, но забудете исправить аналогичный код в другом и возникнут ошибки.
-
В вашей программе есть очень длинные методы/функции. Как правило, человек не может полностью воспринимать и оценивать правильность кода, если этот код занимает больше 2-3 десятков строк. Такие методы и функции следует разделять на несколько более мелких и делать одну общую функцию, которая будет последовательно вызывать эти методы. Никогда не пытайтесь сократить длину кода записывая по несколько операторов в одной строке!!! Это один из самых худших вариантов организации программы и я вам даю 100% гарантию, что такой код в итоге приведёт к ошибкам!
-
Длинный список параметров функции/метода/конструктора. Большое количество параметров обычно не только усложняет понимание того, что, что делает этот метод или функция, но и усложняет понимание кода, использующего эти функции. Если Вам реально нужно, что бы функция принимала очень много параметров – просто вынесите эти параметры в отдельную структуру (либо класс), дав этой структуре разумное и понятное имя, и передавайте функции ссылку (либо указатель) на объект этой структуры или класса.
-
Большие классы так же требуют рефакторинга. Если у Вас в программе есть один или несколько больших (больше пары-тройки десятков строк кода) классов, Вам следует немедленно разделить их на более мелкие и включить объекты этих классов в один общий класс. Причина этого та же самая, что и в предыдущем пункте.
-
Слишком много временных переменных так же являются признаком плохого кода, который требует рефакторинга. Как правило, много временных переменных встречаются в излишне “раздутых” функциях – когда Вы сделаете рефакторинг таких функции, скорее всего и количество временных переменных в каждой из них станет меньше и код станет значительно понятнее и удобнее
-
Много “беспорядочно” хранящихся данных, которые связаны логически и их можно было бы объединить в структуру, либо класс. Логически связанные данные всегда стоит хранить в структурах/классах, даже если это всего 2-3 переменных – хуже от этого никому не станет, а вот код станет значительно понятнее.
-
Если объекты одного класса слишком много/часто обращаются к (ссылаются на) данным другого объекта – Вам следует пересмотреть функционал объектов. Возможно, Вы приняли неверное архитектурное решение и его надо поменять как можно раньше, пока эта ошибка не расползлась по всему коду.
-
Старайтесь не хранить слишком много глобальных переменных. Если же Вам и в самом деле нужно именно столько и никак не меньше глобальных объектов – попробуйте хотя бы сгруппировать их в структуры/классы, либо хотя бы просто вынесите их в отдельный namespace – тогда шанс того, что вы случайно используете какую-то переменную по ошибке, станет значительно ниже.
Для чего нужен рефакторинг?
- чтобы сделать код более понятным.
Разбираться в горах старого кода сложно даже “старичкам”, а что говорить о новичках! Рефакторинг помогает недавно пришедшим на проект программистам быстрее освоиться. Ведь если вы платите за время программиста, то в ваших интересах, чтобы он работал быстрее.
- для ускорения разработки, чтобы код был проще и работал быстрее.
Для расширения функциональности программы лучше не “лепить” дополнительный код поверх старого, а сначала провести рефакторинг. Задача тут та же, как и у сверления зуба, когда вам на кариес накладывают пломбу — подчистить старое, чтобы новое встало лучше.
- для улучшения стабильности работы программы.
Чем лаконичнее вы изъясняетесь, тем проще и понятнее вас слушать. Как людям удобно общаться с теми, кто говорит чётко, кратко и по делу, так и IT программы, имеющие наиболее лаконичный код, работают лучше.
Определение Мартина Фаулера
Вопрос «Что такое рефакторинг?» часто возникает у программистов-новичков, а иногда и у более опытных разработчиков. Поэтому он регулярно всплывает на форумах в духе StackOverflow.
Там в качестве ответа на вопрос приводят цитату из книги «Refactoring: Improving the Design of Existing Code» за авторством Мартина Фаулера:
Рефакторинг – это контролируемая техника совершенствования структуры существующего кода. Суть рефакторинга заключается во внесении серии мелких изменения (с сохранением функциональности приложения), каждое из которых «слишком мелкое, чтобы тратить на него время». Тем не менее эффект от внесения всех этих изменений достаточно ощутимый.
Также в этой книге рекомендуется выполнять рефакторинг пошагово, чтобы исключить появление ошибок. А пользователи StackOverflow советуют каждое изменение сопровождать применением юнит-тестов. И хотя многие отрицают столь тесную связь этих двух операций, большинство опытных кодеров все же не упускают возможности задействовать тесты на любом из этапов разработки или модификации ПО.
Зачем нужен рефакторинг
Когда программисты пишут код, они решают определенную задачу. Иногда происходит так, что решить ее нужно в очень сжатые сроки. От спешки страдает не только программист, но и код: он становится сложным, хаотичным и неструктурированным.
Неструктурированный код можно сравнить с неструктурированным текстом — без заголовков и абзацев. Чтобы структурировать такой код и сделать его понятнее, разработчики используют рефакторинг.
Американский программист и автор множества книг по разработке ПО Мартин Фаулер определяет рефакторинг как «изменение внутренней структуры ПО без изменения его наблюдаемого поведения, призванное облегчить его понимание и удешевить модификацию». Разработчики переписывают какие-то части кода, чтобы они стали понятнее, лаконичнее, а еще — чтобы было проще добавлять новую функциональность.