Как рефакторинг приложения позволил ритейлеру оптимизировать расходы

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

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

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

С какой задачей пришел клиент

К SimbirSoft обратился крупный производитель и ритейлер товаров для дома. Задача — сделать редизайн мобильного приложения на платформах iOS и Android. Забегая вперед скажем, что большой блок задач пришелся на рефакторинг. Ниже объясним подробнее.

Заказчик хотел полностью переработать концепцию приложения, придать современный вид и добавить новые функции с целью — привлечь новых пользователей и улучшить UX (User Experience, опыт пользователя при взаимодействии с приложением). Основная бизнес-задача — повысить конкурентоспособность и полезность основных продуктов.

Какое решение предложили

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

При аудите выявили, что:

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

Стало понятно, что написание нового кода в такой среде будет трудозатратно, как и поддержка текущей функциональности. Взаимодействие «старого» и «нового» в коде может вызвать непредсказуемое поведение приложения. Таким образом, возрастает риск не выпустить проект в срок. Всей командой стали думать, что с этим делать.

Опираясь на результаты аудита, предложили и согласовали с заказчиком следующий план действий:

• Решить текущие проблемы приложения и поддерживать его функциональность.
• Утвердить единый стиль кода и зафиксировать его документально, чтобы с этого момента все изменения в коде описывать единообразно. Это поможет минимизировать риски.
• Чтобы комплексно решить остальные проблемы, но не откладывать запуск новых фич и дизайн, предложили параллельно провести рефакторинг текущей кодовой базы. Такая мера позволяет переработать 60-70% кода в удобный формат. 
• Параллельно запускать работу над новым дизайном и внедрением ключевых фичей.

Что делали

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

Чтобы приступить к работе, мы:

• Оценили трудозатраты и сроки для каждого предлагаемого рефакторинга
• Реорганизовали репозиторий кода и настроили процесс непрерывной интеграции
• Обсудили с командой предстоящие изменения
• Оценили влияние планируемых изменений на код

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

Самая большая проблема, с которой нам предстояло столкнуться при рефакторинге, — огромное количество side effects (побочных эффектов) в текущем коде. Хотя основная функциональность приложения не подверглась изменению, могли возникнуть проблемы «на стыке» экранов или при переиспользовании общих функций. Например, если требовалось убрать устаревший слой кода, но в нем была одна «живая» строка, то для корректной работы логики в коде ее нужно перенести. В свою очередь, это может вызвать новое поведение приложения. 

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

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

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

Какие результаты получили

По итогам работы приложение преобразилось как снаружи, так и внутри. Мы переделали его на 75%. Рейтинг приложения после обновления вырос на 0,5 пунктов до 4,4.

Наша команда переработала и дополнила дизайн-систему, обновила все элементы интерфейса. Работа «под капотом» заняла, конечно, львиную долю времени. Мы удалили порядка 20% ненужного и неиспользуемого кода, поскольку он только утяжелял приложение и усложнял команде поиск быстрых и нужных решений. Порядка 30% кода сохранили полностью или переработали частично. Речь про ту часть кода, которая направлена на работу текущих функций, — она могла послужить хорошим материалом для будущих изменений.

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

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

Вместо вывода

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

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