Что даёт бизнесу рефакторинг кода и как провести его без потерь

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

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

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

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

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

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

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

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

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

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

В коде могут встречаться короткие методы, которые используются всего один или два раза. Например, в приложении для бронирования отелей есть функция, которая проверяет, доступен ли выбранный номер. Если эта проверка используется только при создании брони, можно просто вставить логику проверки в место вызова, а саму функцию удалить. Это называется Inline Method — встраивание метода. Такой подход делает код компактнее, а структуру программы — проще.

В программировании класс является шаблоном для создания объектов. Он описывает, какие данные (поля) будут хранить и какие действия (методы) будут выполнять разные элементы. Например, при разработке маркетплейса может использоваться класс «Заказ», который отвечает за хранение информации о заказе и его обработку. Однако если в этом классе находятся элементы, связанные с обработкой платежей, например, с расчётом комиссии или подтверждением транзакции, их логичнее перенести в отдельный класс «Платёж». Для этого применяют Move Field или Move Method — перемещение поля или метода. Это делает структуру программы более логичной.

Во время разработки часто возникают ситуации, когда простые значения, такие как числа или строки, обозначают сложные данные. Например, число может символизировать цену товара и при этом быть связано с дополнительной информацией, такой как наименование валюты и размер скидки. В таком случае создают класс, который содержит само число и все характеристики, которые к нему относятся. Этот подход называется Replace Data Value with Object — замена примитивного значения объектом.

В программном коде могут встречаться массивы — это списки однотипных данных, например, перечень товаров в магазине. Если каждый товар имеет свои уникальные свойства, такие как стоимость, описание и наличие на складе, можно применить Replace Array with Object — замену массива объектом. Вместо массива для каждого товара создаётся отдельный класс, который хранит всю нужную информацию и позволяет взаимодействовать с каждым объектом по отдельности. Это помогает структурировать данные и сделать их более удобными для поиска, обновления и дальнейшей обработки.

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

Состав команды, которая работает над проектом, может меняться, и новым разработчикам бывает сложно разобраться в чужом коде. Чтобы упростить его поддержку, используют Rename Method — переименование метода. Если название метода не отражает суть, его переименовывают, чтобы упростить понимание кода и вызов нужных функций. Например, если метод носит общее название вроде «process», но на деле отвечает за вычисление скидок, переименование в «calculateCashback» сразу прояснит его назначение.

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

Рассмотрим, как сделать рефакторинг шаг за шагом и не нарушить функциональность системы.

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

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

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

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

Рассмотрим, с какими проблемами можно столкнуться во время рефакторинга и как их избежать.

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

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

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

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

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

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

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

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