Рефакторинг — слово, которое прочно вошло в лексикон каждого IT-специалиста по мере развития IT-технологий. Попробуем разобраться что кроется за этим, столь употребимым, сегодня словом, каковы предпосылки для осуществления рефакторинга, какие основные методы проведения рефакторинга и какие основные нюансы должны быть учтены при проведение данной процедуры.
Рефакторинг — это изменение уже существующего программного кода и смежных ресурсов, которое может как затрагивать, так и оставлять бизнес-логику без изменений. Причины, ведущие к рефакторингу могут быть самыми разнообразными. При этом все они могут быть вызваны как «естественными» причинами, как, например, выпуск новых версий программной платформы, новых плагинов и библиотек, так и «искусственными», такими как фундаментальные ошибки логики, изменившиеся требования рынка к функциональности или интерфейсу приложения.
К первой, из этих категорий причин, можно отнести возможность повышения быстродействия приложения, ввиду обновления программной платформы. Хорошим примером будет обновление PHP с версии 5 до версии 7, которое произошло несколько лет назад. Тогда быстродействие интерпретатора PHP, в целом, выросло практически в два раза. Однако наиболее частым является не обновление того или иного интерпретатора или компилятора, а обновление базовых фреймворков и библиотек приложения. В таком случае, обычно, бизнес-логика приложения затрагивается не слишком сильно. Обычным делом является вычленение устаревших функций, рекомендованных к удалению, взамен которых идет имплементация их новых версий. Такой вид рефакторинга может быть произведен относительно быстро и не потребует больших затрат времени. При этом, такой тип рефакторинга можно осуществлять на отдельной ветке одного и того же приложения. Для мониторинга прогресса операции рефакторинга может быть поднят отдельный выделенный или виртуальный сервер, который будет независим от окружения промышленной эксплуатации.
Вторая категория потенциальных причин рефакторинга более глобальна и зачастую требует изменения значительной части приложения, так как далеко не всегда изменение только отдельных библиотек способно привести к существенным улучшениям работы последнего. В некоторых случаях фундаментальные ошибки приложения, которые были допущены в виду неразрешимой комплексной задачи или, банально, из-за малоопытности разработчика, могут привести к полному переписыванию коду всего или практически всего приложения. К примеру к такому рефакторингу могут привести ошибки в проектирование базы или баз данных приложения, ошибочный выбор архитектурных решений кодовой базы, фатальные ошибки, допущенные на различных этапах тестирования. Пожалуй, такой вид рефакторинга можно назвать наиболее неприятным, поскольку он возвращает вас на этап решения уже, казалось бы, решенных задач, как связанных с бизнес-логикой, так и с выбором той или иной технологии или концепции для решения конкретной конечной задачи.
В этом случае, отдельной веткой репозитория вряд ли получится отделаться. Иногда может потребоваться полная копия аппаратного окружения, а порой и вообще его полное перестроение. Дело в том, что база данных является неким центром или скелетом бизнес-логики. Структура базы данных, особенно, если мы говорим о «монолитном» приложение, является несущей конструкцией всего приложения, а значит и бизнеса. Причина, которая ведет к рефакторингу может быть вызвана, также, не конкретной ошибкой на этапе проектирования, а неразрешимыми не «кастыльным» путем трудности производительности. Зачастую потенциальная нагрузка на приложение плохо просчитывается на этапе его проектирования. Нагрузочные тесты не создаются или попросту опускаются в виду эфемерных, более приоритетных задач. Конечно, на сегодняшний день существует большое количество решений, позволяющих «работать» с возрастающей нагрузкой и отказоустойчивостью, среди них можно выделить кэширование или переход на микросервисы, однако далеко не всегда эти подходы, позволяют внести оперативные позитивные изменения, которые существенно отразятся на работе приложения, и, как следствие, на бизнесе его конечного владельца.
Подход, заключающийся в применение микросервисов, в настоящее время является чрезвычайно популярным, однако его использование неизбежно сопряжено с большими временными и трудозатратными издержками, другими словами решая одни задачи и проблемы, микросервисы способны породить другие. Например в том случае, если миросервисов становится столько, что проектирование нового функционала связанно с изменением сложной схемы взаимодействия микросервисов, внедрением новых программных продуктов, например отдельные микросервисы могут использовать принципиально иные базы данных.
Таким образом, можно прийти к выводу, что одним из простых принципов привентизации рефакторинга может служить принцип KISS (Keep It Simple Stupid), который дает довольно четкие рекомендации о том, что приложение должно оставаться максимально простым и «прозрачным» для всех разработчиков, что повлечет за собой минимизацию большинства операций с вашим приложением. Именно такой фундаментальный подход можно считать принципиально правильным, его можно применять на всех жизненных стадиях разработки программного обеспечения.
Рефакторинг фронтальной части приложения также очень популярный случай, который, условно, может быть отнесен ко второму типу рефакторинга по нашей градации. Пожалуй в современном интернете практически нету ресурсов, которые бы оставались неизменными в случае их создания более чем 17-20 лет назад. Такой тенденции способствовало не только появление принципиально новых типов интерфейсов и верстки, но и бурно развивающиеся в последние годы стандарты и спецификации JavaScript — единственной технологии программирования динамических интерфейсов.
Отделение серверного кода и клиентского, позволяет поддерживать и рефакторить каждый из них независимо друг от друга. В этом плане внедрение микросервисной архитектуры упрощает задачу. Изменение интерфейсов зачастую связано с визуальной частью приложения и дизайном намного больше, чем со сложной бизнес-логикой и выбором серверных приложений, ответственных за конкретные задачи, будь то кэширование или, например, очереди. При этом такой рефакторинг также требует дополнительного стенда для работы и мониторинга процесса.
В этой статье мы разобрали понятие «рефакторинг», его основные причины и возможные пути решения. Конечно, невозможно учесть абсолютно все нюансы и гарантировать то, что процедура рефакторинга, особенно серверного кода, никогда не затронет серьезным образом какое-либо приложение, однако следуя не сложным принципам можно минимизировать издержки временных и трудозатрат, которые могут сопутствовать потенциальной процедуре рефакторинга.
Специалисты Creative Lab имеют большой опыт разработки систем любой сложности. Больше информации о нас можно получить на главной странице.
