Здравствуйте, в этой статье мы постараемся ответить на вопрос: «Что такое рефакторинг кода и для чего он нужен». Если у Вас нет времени на чтение или статья не полностью решает Вашу проблему, можете получить онлайн консультацию квалифицированного юриста в форме ниже.
Рефакторинг кода является необходимой частью разработки программного обеспечения, а также процессом, который следует не только не бояться, но и приветствовать. Хотя на первый взгляд рефакторинг может показаться сложным и довольно затратным по времени, но именно он является ключевым инструментом для поддержания качества кода и обеспечения его эффективности и гибкости в долгосрочной перспективе.
-
Рефакторинг проводят для снижения технического долга, улучшения читаемости и тестируемости кода, повышения эффективности разработчиков.
-
Рефакторинг нужно планировать и проводить постепенно, снижая технический долг, чтобы рефакторинг не становился вынужденной мерой. Научитесь оценивать время и риски.
-
Делайте упор на проблемы тестируемости кода, чтобы дальнейшее сопровождение было удобным и понятным для всех участников команды.
-
Не забывайте делиться опытом, проводить код-ревью, выбирать единые инструменты и принимать соглашения в команде.
-
Вкладывайтесь в процесс. Внедряйте и автоматизируйте процессы по контролю качества кода на любом из этапов разработки.
-
Выбирайте удобный подход. Перед внесением больших изменений пишите автоматические тесты, если это невозможно, рассматривайте другие безопасные способы для проведения рефакторинга.
Зачем нужен рефакторинг?
Есть гласное правило для всех программистов – код должен быть лаконичным, хорошо структурированным и понятным для разработчиков, работающих с ним. Проблема в том, что написать такой код с первого раза – очень сложная задача. Каким бы опытным ни был программист, начальство заставит его спешить, заказчики будут менять требования по ходу разработки, а иногда код будет становиться непонятным из-за банального недосыпа. Более того, сами языки программирования регулярно совершенствуются и обретают новые возможности, позволяя заметно сократить количество кода. Поэтому и нужен рефакторинг.
Ожидаемые преимущества рефакторинга:
-
Улучшение объективной читаемости кода за счет его сокращения или реструктуризации.
-
Провоцирование разработчиков на более вдумчивое написание ПО с соблюдением заданной стилистики и критериев.
-
Подготовка плацдарма для создания переиспользуемых кусков кода.
-
Упрощение поиска ошибок в большом объеме кода.
Методики рефакторинга
Разработчики и специалисты в области рефакторинга часто называют десятки различных тактик переработки кода, но почти все они четко привязаны к изменяемому компоненту (объекту, функции и т.п.), поэтому нет смысла их все перечислять. Обобщая, есть три основных способа выполнить рефакторинг:
-
Red-Green-Refactor. Это некий аналог «На старт, внимание, марш!». Находим кусок кода для переработки, пишем юнит-тест, переходим к переписыванию.
-
Абстракция. Эта стратегия используется, когда нужно почистить дубликаты. Разработчиками придумываются абстрактные классы или другие классы высокого уровня, чтобы вынести туда повторяющиеся методы.
-
Фрагментация. Стратегия изменения кода с целью увеличить количество компонентов, но сделать сами компоненты меньше. Что-то в духе методик планирования задач, часто применяемых для повышения личной эффективности.
Целесообразность применения рефакторинга
Рефакторинг бывает двух вариантов: запланированный либо проводящийся по мере надобности.
Плановый – это тот, для которого в цикле разработки изначально заложено необходимое время. К примеру, он будет выполняться раз в полгода, или после каждых четырех спринтов.
Крупные компании часто создают специальные группы, работа которых состоит исключительно в рефакторинге старых кодов (легаси-кода в больших фирмах обычно много). После этого они становятся более понятными и простыми в использовании для других сотрудников.
Второй вариант – рефакторинг по мере надобности. Это когда необходимо внести в код новые возможности, но они плохо интегрируются со старыми. Тогда приходится их пересматривать и реорганизовывать.
Оценка эффективности рефакторинга
Анализ и рефакторинг сделан успешно, если в результате вы имеете чистый, простой и понятный код.
К примеру, если количество покупателей в программе обозначено буквой Z, то лучше вместо неё поставить customerCount. Так код будет выглядеть яснее, и выполняемые в нём операции – тоже.
Если какая-то часть кода повторяется два раза и более, то есть смысл задать её в виде функции или метода. Тогда эти повторяющиеся фрагменты не нужно будет выискивать по всему коду, понадобится сделать замену лишь в одном месте.
Размеры функций, методов и классов тоже имеют значения. Если функция не влезает целиком в экран, то её нужно разбить на две части, тогда код будет легче читаться.
Еще один способ упростить код – все функции собрать в самостоятельный файл, а потом уже ввести его в программу.
Лучшие практики эффективного рефакторинга кода
Чтобы обеспечить успешный и эффективный рефакторинг, крайне важно следовать некоторым лучшим практикам. Вот несколько рекомендаций по эффективному рефакторингу кода:
- Проводите регулярные проверки кода: проверки кода помогают командам определить области кодовой базы, которые требуют рефакторинга и потенциально могут уменьшить избыточность кода и улучшить удобство обслуживания.
- Используйте системы контроля версий. Используйте системы контроля версий, такие как Git, для отслеживания изменений кода во время рефакторинга. Это позволяет вам вернуться к предыдущим версиям кодовой базы, если что-то пойдет не так, или отслеживать эволюцию кода с течением времени.
- Создайте четкий план и цель. Имейте четко определенную цель и план процесса рефакторинга. Это помогает сделать процесс рефакторинга целенаправленным, эффективным и согласованным с требованиями вашего проекта.
- Внедряйте автоматизированные тесты. Автоматизированные тесты гарантируют, что ваш рефакторинг кода работает должным образом, и помогают обнаружить любые нежелательные изменения в функциональности. Обязательно охватывайте различные случаи, а написание тестов перед рефакторингом может послужить подстраховкой.
- Вносите небольшие, постепенные изменения. Вместо одновременного внесения значительных изменений в кодовую базу выбирайте небольшие, постепенные изменения. Это сводит к минимуму риски и позволяет более эффективно оценить влияние ваших усилий по рефакторингу.
- Общайтесь со своей командой: убедитесь, что ваша команда осведомлена о планах и ходе рефакторинга. Сотрудничество и обсуждение процесса рефакторинга помогает добиться лучших результатов и предотвратить возникновение потенциальных проблем.
Следование этим передовым практикам может помочь сделать процесс рефакторинга более систематическим, эффективным и успешным.
Как договориться с коллегами?
Может оказаться, что менеджеру не понравится, что вы ковыряетесь в старом коде вместо того, чтобы делать новый. А может быть, и коллегам не понравится, что вы трогаете старый код с риском сломать его — особенно если это их код.
Что ж, самое простое тут — это менеджер. Рефакторинг — способ двигаться быстрее, так что можно попробовать зайти с экономической стороны вопроса. Но, в целом, можете просто ничего про рефакторинг не рассказывать, не его это дело. Фича готова? Готова. А как именно — это уже детали реализации. Самое главное — помнить, что вы профессионал и вам лучше видно, как делать свою работу.
Если против вас ополчилась команда и договориться не удалось никак, то тут все плохо. Обычно такие глубокие разногласия приводят к разводам — кто-то уходит, а кто-то остается. Вопрос лишь в том, кто у руля.
На этом мы, пожалуй, и закончим знакомство с НАСТОЯЩИМ рефакторингом.
И теперь у вас уже достаточно инструментов, чтобы безопасно и качественно приводить свою кодовую базу в порядок.
Для чего нужен рефакторинг?
Существует несколько причин. Например, погоня за простотой и лаконичностью кода. Сторонники этой теории считают, что код должен быть максимально кратким, даже если для его понимания нужно несколько десятков строк комментарий. Другие разработчики уверены, что код должен подвергаться рефакторингу настолько, чтобы он был понятен с минимальным количеством комментариев. Каждая команда выбирает свою позицию, но нужно помнить, что рефакторинг — это не сокращение. Его главная цель — улучшить структуру кода. В эту глобальную цель можно включить несколько задач:
- Рефакторинг улучшает понимание кода, который написан другим разработчиком;
- Помогает искать и устранять ошибки;
- Позволяет повысить скорость разработки ПО;
- В целом улучшает композицию программного обеспечения.
Представим такую ситуацию: мы открыли кафе, построили там классную кухню и наняли шеф-повара. Когда кафе только запускалось, в меню были самые простые блюда, которые можно было разогреть в микроволновке. Вы купили микроволновку и поставили на кухне. Рядом разместили стеллаж для всего нужного.
Через два месяца дела пошли лучше, и мы решили добавить в меню выпечку. Купили духовой шкаф, протянули провода, добавили рядом стойку с подносами. Место на кухне уменьшилось, повар всё время перешагивает через провода и обходит стойку, но работать можно.
Ещё через месяц поставили фритюрницу и миксер для теста. К ним тоже протянули провода, добавили рядом шкафы для утвари и наняли второго повара. В итоге на кухне полный бардак, всё друг другу мешает, а блюда готовить неудобно. Если мы захотим добавить новую плиту, то это будет уже сложно: места нет, хотя по площади можно поставить хоть две таких плиты.
В этот момент приходит кухонный проектировщик и рисует всё заново: где что должно стоять.
Через неделю на кухне всё по-другому: оборудование стоит так, чтобы не мешать поварам, провода спрятаны в короба, а стойки с оборудованием не загораживают выход. При этом меню в кафе не изменилось: посетители даже не знают, что у нас что-то происходило на кухне, потому что мы оптимизировали процессы, а не меню. Это и есть рефакторинг — когда мы меняем что-то внутри так, что снаружи это незаметно, но работать дальше становится проще.
Поддержка рефакторинга руководством
Инвестиции в инфраструктуру и техническое обслуживание могут быть непопулярны в вашей компании.
Легко утверждать, что время, потраченное на рефакторинг, — это время, проведенное вне новой работы.
Но стоит взглянуть на преимущества рефакторинга и на то, как они связаны с рабочим процессом, клиентами, доходами и ростом бизнеса. Хорошо проведенный рефакторинг улучшает код, который должен хорошо функционировать, чтобы предоставлять эффективные обновления и модные функции, отвечающие потребностям новых и постоянных клиентов. Таким образом компания-разработчик программного обеспечения остается конкурентоспособной даже после успешного выпуска продукта.
Еще лучше заручиться поддержкой высшего руководства для рефакторинга, подсчитав, сколько времени команда в настоящее время тратит на исправление ошибок или ошибок, возникших из-за проблем в исходном коде. Будьте конкретны — это один час в день? Два часа в день? Ведите записи в течение недели, вы можете быть шокированы, узнав, что ваша команда тратит недели или месяцы каждый год на исправление устаревшего кода.
Зачем нужен рефакторинг
Если код хорошо структурирован и легко воспринимается другими программистами, то его поддержка и доработка не вызывает особых трудностей. Однако добиться такого результата с первого раза удается далеко не всегда. Чаще всего разработчики торопятся, поскольку в процессе работы меняются требования и задачи, а сроки сдачи проекта остаются прежними. Более того, после тестирования находятся баги, которые нужно оперативно исправлять.
Как итог – код становится сложным, громоздким и непонятным. Даже хорошо структурированный исходник не исправит ситуацию. Разработчики прекрасно знают о существовании этой проблемы, ведь запутаться можно не только в чужом, но и в своем коде.
Решить проблему помогает рефакторинг. С его помощью можно:
- сделать код удобочитаемым для любого участника команды, тем самым упростить дальнейшую разработку;
- ускорить процесс работы над проектом;
- сократить время поиска ошибок;
- сохранить исходную архитектуру программы, сделав при этом ее структурированной.
Декомпозиция рефакторинга
Как и для пользовательских историй, разбиение на подзадачи важно и для рефакторинга, так как это помогает поддерживать постоянный поток процесса разработки. В Таблице 1 представлены некоторые полезные методы для декомпозиции задач по рефакторингу и пример по каждому из них.
| 1. По пользовательским сценариям или пользовательским историям — рефакторить инкрементально историю за историей, или сценарий за сценарием, или каким-то иным способом выделить несколько функциональных областей для их последовательного рефакторинга. | |
| Оптимизировать запросы к БД и внедрить кеширование данных, чтобы система работала быстрее | …Отрефакторить все функции управления пользователями… Далее функционал просмотра каталога… Далее функционал проверки работоспобности |
| 2. По компонентам — сначала провести рефакторинг кода одного компонента, а потом перейти к следующему. | |
| Поменять процесс индексирования на пакетную обработку, чтобы процесс был как минимум в 2–3 раза быстрее для средней веб-страницы | …Рефакторим парсинг (компонент парсера)… Далее экстрактор сущностей (компонент-анализатор)… Далее хранение в индексе (компонент индекса) |
| 3. По интерфейсам/реализациям — сначала создаем интерфейс и оборачиваем им старую функциональность, а потом рефакторим саму функциональность. | |
| Извлечь все параметры синтаксического анализа в xml-файл конфигурации, чтобы процесс можно было легко настроить без изменения кода | …Ставим PINGID Protocol server и тестим его с помощью провайдера идентификации mock…Читаем конфигурацию из файла в любом формате… Рефакторим функциональность конфигурирования, чтобы поддерживать в должном состоянии валидацию структуры и схемы |
| 4. Уменьшение устаревшего кода / Разделение монолита — постепенно переносим функциональность из legacy-компонента (компонент с устаревшим кодом) в новые; как только все будет перемещено, удаляем старый код. | |
| Заменить базу данных пользовательским поисковым индексом, чтобы производительность индексирования и поиска повысилась в 10-20 раз | …Сначала переносим индексацию данных в поисковый индекс… Далее переносим словари |
| 5. Точечный рефакторинг / Инкапсуляция результата – сначала рефакторим там, где это нужно, но потом извлекаем измененную сущность и инкапсулируем ее в компонент, класс или метод/функцию. | |
| Заменить ad hoc синтаксический анализ на анализ на основе грамматики так, чтобы изменение правил синтаксического анализа стало простым и без необходимости кодирования | …Рефакторим текущий код так, чтобы он использовал нотацию грамматик… Извлекаем эту функциональность и помещаем ее в движок грамматик |
Подход к переработке кода каждый специалист выбирает сам, отталкиваясь от особенностей корректируемой функции, объекта или иного компонента. Наиболее распространенными являются такие способы:
-
Red-Green-Refactor. Предполагает поиск участка кода, нуждающегося в коррекции, написание юнит-теста и последующего переписывания. Созданный заранее текст позволяет управлять софтом, задавая направление для работы кода
-
Фрагментация — напоминает методику планирования задач, только в данном случае уменьшаются компоненты, но их количество возрастает. Фрагмент изначального текста вносится в новый code с четким названием функции, что положительно сказывается на читабельности и снижает сложность дальнейшей работы
-
Абстракция — эффективный способ нейтрализации повторяющихся участков. Сначала необходимо придумать несколько абстрактных и других высоких классов, куда потом будут перемещаться дубликаты. Данная тактика подходит для планомерной коррекции структуры, регулярного выпуска релизов до окончания процесса оптимизации. При грамотном применении удается упростить коррекцию в потенциально проблемной ветке на этапе объединения кода
-
Compose — помогает бороться с повышенной сложностью кода с помощью совокупности тактик. Среди них: Replace Temp with Query, разделение временных переменных, Inline Method, а также Inline Temp
Разная квалификация разработчиков
Другая проблема — это менее опытные коллеги. Разница между опытным и неопытным разработчиком — просто гигантская. Здесь нельзя сравнить программиста с грузчиком, водителем или какой-то другой профессией.
Сильный программист может быть в 20 раз продуктивнее слабого. Плюс слабый программист порождает проблемный код. Если вы сажаете потом за доработку этого кода сильного программиста, он будет работать медленнее!
По опыту обычно проблема в том, что плохой код обычно очень витиеватый, сложный для понимания, хрупкий (чуть что поменяешь и он где то начинает падать).Разбираться в таком коде — сущий ад. И зачастую все заканчивается тем, что начинают этот код просто переписывать с нуля. А это новые затраты для проекта.
- Обнаружив, что в программу необходимо добавить новую функциональность, но код программы не структурирован удобным для добавления этой функциональности образом, сначала произведите рефакторинг программы, чтобы упростить внесение необходимых изменений, а только потом добавьте функцию.
- Перед началом рефакторинга убедитесь, что располагаете надежным комплектом тестов. Эти тесты должны быть самопроверяющимися.
- При применении рефакторинга программа модифицируется небольшими шагами. Ошибку нетрудно обнаружить.
- Написать код, понятный компьютеру, может каждый, но только хорошие программисты пишут код, понятный людям.
Самый важный урок, который должен преподать данный пример, это ритм рефакторинга: тестирование, малые изменения, тестирование, малые изменения, тестирование, малые изменения. Именно такой ритм делает рефакторинг быстрым и надежным.
Рефакторинг и производительность
С рефакторингом обычно связан вопрос о его влиянии на производительность программы. С целью облегчить понимание работы программы часто осуществляется модификация, приводящая к замедлению выполнения программы. Рефакторинг, несомненно, заставляет программу выполняться медленнее, но при этом делает ее более податливой для настройки производительности. Секрет создания быстрых программ, если только они не предназначены для работы в жестком режиме реального времени, состоит в том, чтобы сначала написать программу, которую можно настраивать, а затем настроить ее так, чтобы достичь приемлемой скорости.
Второй подход предполагает постоянное внимание. В этом случае каждый программист в любой момент времени делает все от него зависящее, чтобы поддерживать высокую производительность программы. Это распространенный и интуитивно привлекательный подход, однако он не так хорош на деле. Модификация, повышающая производительность, обычно затрудняет работу с программой. Это замедляет создание программы. На это можно было бы пойти, если бы в результате получалось более быстрое программное обеспечение, но обычно этого не происходит. Повышающие скорость усовершенствования разбросаны по всей программе, и каждое из них касается только узкой функции, выполняемой программой.
С производительностью связано то интересное обстоятельство, что при анализе большинства программ обнаруживается, что большая часть времени расходуется небольшой частью кода. Если в равной мере оптимизировать весь код, то окажется, что 90% оптимизации произведено впустую, потому что оптимизировался код, который выполняется не слишком часто. Время, ушедшее на ускорение программы, и время, потерянное из-за ее непонятности — все это израсходовано напрасно.
Третий подход к повышению производительности программы основан как раз на этой статистике. Он предполагает создание программы с достаточным разложением ее на компоненты без оглядки на достигаемую производительность вплоть до этапа оптимизации производительности, который обычно наступает на довольно поздней стадии разработки и на котором осуществляется особая процедура настройки программы. Начинается все с запуска программы под профайлером, контролирующим программу и сообщающим, где расходуются время и память. Благодаря этому можно обнаружить тот небольшой участок программы, в котором находятся узкие места производительности. На этих узких местах сосредоточиваются усилия, и осуществляется та же самая оптимизация, которая была бы применена при подходе с постоянным вниманием. Но благодаря тому, что внимание сосредоточено на выявленных узких местах, удается достичь больших результатов при значительно меньших затратах труда. Но даже в этой ситуации необходима бдительность. Как и при проведении рефакторинга, изменения следует вносить небольшими порциями, каждый раз компилируя, тестируя и запуская профайлер. Если производительность не увеличилась, изменениям дается обратный ход. Процесс поиска и ликвидации узких мест продолжается до достижения производительности, которая удовлетворяет пользователей.
При проведении рефакторинга важным предварительным условием является наличие надежных тестов.
Правила разработки тестов
- Делайте все тесты полностью автоматическими, так чтобы они проверяли собственные результаты.
- Комплект тестов служит мощным детектором ошибок, резко сокращающим время их поиска.
- Чаще запускайте тесты. Запускайте тесты при каждой компиляции — каждый тест хотя бы раз в день.
- Получив сообщение об ошибке, начните с создания теста модуля, показывающего эту ошибку.
- Лучше написать и выполнить неполные тесты, чем не выполнить полные тесты.
- Подумайте о граничных условиях, которые могут быть неправильно обработаны, и сосредоточьте на них свои тесты.
- Не забывайте проверять, чтобы в случае возникновения проблем генерировались исключительные ситуации.
- Опасение по поводу того, что тестирование не выявит все ошибки, не должно помешать написанию тестов, которые выявят большинство ошибок.