Создание проекта с нуля дает разработчикам определенную свободу. Но что делать, если нужно доработать и обновить продукт, существующий уже более 10 лет? В этом материале мы расскажем о том, как работать с унаследованным кодом, какие сложности могут возникнуть и как сделать всю контентную часть управляемой.
Количество часов в проекте: 3790 часов Технологический стек: React, Laravel Формат работы: выделенная команда Ответственные со стороны заказчика: менеджер по продукту, технический директор
RU-CENTER (ex Nic.ru) — один из крупнейших в России регистраторов доменных имен и хостинг-провайдеров. Компания является флагманом группы компаний RU-CENTER Group, в свою очередь входящей в холдинг «РБК».
Цель проекта — увеличить конкурентное преимущество за счет нового дизайна, внедрения SEO-рекомендаций и реализации нового функционала, а также сократить расходы на поддержку старого веб-приложения.
Для достижения поставленных целей команде разработки предстояло выполнить 4 крупных задачи:
Главная сложность в подобных проектах заключается в том, что команде нужно быть максимально автономной и при взаимодействии с другими командами снижать координационные издержки. Помимо этого можно выделить следующие ограничения:
RU-CENTER — технологическая компания со своим штатом разработчиков и отвечающими за разные направления командами. Например, одна группа разработчиков отвечает за личный кабинет клиента, а другая за транзакции.
Как это часто бывает, эти команды заняты поддержкой и разработкой отдельных проектов, и их ресурса не хватает для выполнения работ в рамках разовых маркетинговых активностей.
Нанимать в таком случае специалистов — не самый оптимальный вариант, так как обеспечить их постоянным потоком задач не выйдет. Именно в таких случаях на помощь приходит IT-аутсорсинг.
Клиент переживал, что внешний исполнитель может не справиться с проектом, поэтому для первого этапа выделили относительно небольшой объем работ по интеграции нового дизайна на главной странице. Это верный подход, и мы сами всегда поддерживаем старт с чего-то не столь объемного. После успешного выполнения первой задачи последующие этапы уже получилось распараллелить и ускорить процесс поставки.
Для каждого проекта формировалась команда, состоящая из тимлида, фронтенд- и бэкенд-разработчика. Функции DevOps распределялись между участниками команды. При этом зоны ответственности были четко зафиксированы, например: обработка и хранение данных, а также доработки системы администрирования были на внутренней команде.
Постановка задач происходила через внутренний трекер заказчика, чтобы команда могла видеть задачи из бэклога активного спринта. Репозиторий также был на стороне заказчика в корпоративном GitLab. Команде Work Solutions предоставили доступы под VPN. Для демонстрации промежуточных этапов наша команда настроила тестовые стенды и CI с помощью сервиса Rundeck.
Ответственное лицо со стороны заказчика — Product-менеджер. 99% взаимодействия между командами происходило через неё. Она могла подключать к процессу зависимые стороны, выделять дополнительные ресурсы, принимала ключевые решения и знала обо всем, что касалось визуала. На этапах приемки подключался CTO.
Под каждую задачу выделили отдельный этап работ. Перед началом сформировали техническое решение с описанием архитектуры, диаграммой последовательностей и взаимодействий.
Архитектура магазина доменов
Система состоит из множества взаимодействующих между собой модулей и приложений. Например:
За каждую функциональную часть несла ответственность соответствующая команда. Например, за магазин, функционал заказов или личный кабинет пользователя.
Приложение на React визуально устарело, и ему требовалось обновление дизайна. Внутренняя команда разработала макеты, и перед нашими разработчиками стояла задача интегрировать новый дизайн.
Особенность этого проекта в том, что нужно было интегрировать с админ. панелью все блоки. Система позволила гибко управлять любым контентом без редактирования исходного кода.
Вместе с главной страницей изменили основное меню. Все элементы основного и второстепенного меню могут редактироваться через админку.
Также была добавлена возможность скрывать определенные пункты меню от индексации
AMP и турбо-страницы — это способ привлечения и удержания мобильных пользователей. Они делают проще и понятнее чтение контентных разделов. А также уменьшается скорость загрузки страниц.
Перед настройкой разработчики столкнулись с рядом ограничений по контенту и по архитектуре:
Поэтому было предложено вынести весь функционал AMP и турбо-страниц в отдельный сервис web-seo-client, который собирает seo-страницы по контентным блокам каждого типа.
Магазин доменов — встроенное приложение, предназначенное для продажи доменов на вторичном рынке.
Настройка магазина производится в двух местах. В первой админке происходит управление всем, что отвечает за визуал: сео-тексты, описания, рекламные тексты, расположение блоков, картинки, категории и т.д. Есть вторая админка, через которую происходит управление торгами доменов.
Наши разработчики выполнили следующие работы:
При разработке фронтенда ключевая сложность состояла в том, что новый функционал приходилось встраивать в уже существующий. Дизайн-макеты не учитывали того, что на сайте уже есть строго выверенная структура блоков. Например, в хедере заданы все размеры и стили. Любое несоответствие этим параметрам приводило к конфликтам, поэтому приходилось постоянно подгонять и корректировать элементы.
Страницы работают по грубому соответствию URL-адресов, и нельзя записать параметр в адрес, чтобы сопоставить URL в браузере, поэтому с реализацией динамических URL возникли трудности.
Также на стороне сервера были определенные форматы хранения данных, и добавить новые было проблематично.
В контентных блоках при обычном клике не работали ссылки, открыть их можно было только в новой вкладке. Для исправления поведения потребовалось найти код, который отлавливает все клики, проверяет и отменяет действие для ссылок, чтобы с помощью кастомного роутера переадресовывать пользователя без перезагрузки страницы.
Подобных нюансов на проекте было очень много. Поэтому работы с доработкой существующего функционала не могут выполняться с предварительной оценкой.
Такие факторы сильно влияют на скорость внедрения новых решений, и всего невозможно учесть при быстрой оценке работ без аудита.
Работать с унаследованным кодом можно, но при этом нужно учитывать различные форс-мажоры и проявлять гибкость в принятии решений. У нас получилось, и наши наработки до сих пор используются на проекте.
Алевтина Петрикова
Product Manager, RU-Center
Хочу от всей души поблагодарить вашу команду за сотрудничество!
Мне было очень приятно с вами работать: вы крутые инженеры, меня восхищает ваша проактивная позиция, мы всегда могли и договориться, найти решение, разрулить кросс-командные кейсы.
