Логистика, Разработка | Олег Брагинский, Виталий Лажинцев, Сергей Кондратенко
ИТ-разработка – искусство, требующее планирования, координации и технической экспертизы. Основатель «Школы траблшутеров» Олег Брагинский со слушателями школы Виталием Лажинцевым и Сергеем Кондратенко рассказывают, как спасали проект в сложных условиях.
Если заказчик меняет исполнителей, это происходит по разным причинам: от невыполнения работы до «не сошлись характерами». Одна из самых запутанных ситуаций для новой команды – исправление «нерабочего» замысла. Так и хочется спросить: «Почему бы просто не начать с нуля?»
Типичный ответ: «Хочется довести начатое до конца, ведь потрачено много сил, времени и денег». Текущая история связана с бизнесом, активно работающим несколько лет до нашего привлечения. Скорее он «пытался функционировать», ведь итоговый продукт оказался далёк от идеала.
Что же произошло? Начнём с фактов. Около трёх лет назад, теперь уже наш клиент заказал разработку портала, чем-то напоминающего «BlaBlaCar», только для корпоративной структуры.
Система позволяет заказчикам размещать запросы на перевозку, а подрядчикам откликаться и участвовать в аукционе с интересной механикой. Долгий отклик снижает стоимость выполнения работ, стимулируя принимать решения быстро, позволяя нанимателям выбрать выгодный вариант.
«Изюминка» – внутренний умный документооборот, формирующий все необходимые шаблоны: договор и талон заявки, путевой лист, товарно-транспортная накладную и акт сверки.
Это обеспечивает юридическую прозрачность и эффективное управление перевозками, что отличает платформу от конкурентов, где такой функционал отсутствует или реализован частично:
Однако, предыдущая команда выпустила в продакшн версию, мягко говоря сырой и недоработанной. Пользователи сталкивались с многочисленными неудобствами и сбоями.
Никто не исправлял возникающие проблемы, разработчики находили постоянные отговорки: «У нас всё работает» или «Починить нельзя». Баги копились, недовольство росло:
Тогда клиент обратился к нам, чтобы «реанимировать» платформу. Выясняя, что конкретно предстоит исправлять, провели вдумчивый аудит и выявили развесистый букет изъянов. Напрашивалось решение начать разработку с нуля, но система использовалась уже несколько лет.
Собственники не согласились с кардинальным вариантом и потому, что кроме внушительных материальных вложений, потребовался бы и поиск новых инвесторов. Подытожили причины, почему нельзя просто взять и переделать:
- Активное использование площадки. Отключение «неработающей» части ведёт к потере денег владельцев портала и пользователей приложения.
- Нужны внешние финансовые источники на новую разработку.
Встала задача по быстрому исправлению технических и функциональных нестыковок. Как сказал один из наших разработчиков: «Похоже на гигантскую паутину, связанную с подобной. Не паук создаёт новый блок, а сеть сама это делает – всё настолько автоматизировано».
И тут мы поняли, что починить замысел – задача второстепенная. Приоритетом стало разобраться в имеющемся функционале. Но в чём загвоздка, спросите вы? Открываете описание и готово!
Нас поджидал главный сюрприз – документации нет! Вы пробовали разбирать чужой проект без зафиксированных ожиданий и параметров функционирования? Теперь мы в этом профи.
Код представлял из себя «свалку»: предыдущая команда выбрала определенный паттерн программирования, но не стала строго следовать ему. Это не всегда проблема квалификации, а, скорее, следствие отсутствия дисциплины и организованности в работе.
Реализация страдала от отсутствия чётких шаблонов и не имела устойчивого фундамента. Практически весь функционал генерировался динамически, что затрудняло понимание структуры, делало поддержку и расширение если не невозможным, то крайне затруднительным.
Множество зависимостей между компонентами создавало риск поломок при изменениях и замедляло процесс исправлений, вызывая непредсказуемые осложнения:
Мы запросили техническое задание, на основе которого всё создавалось, но выяснилось, что его тоже нет. Это вызывало ещё большую неопределённость и затрудняло понимание механики.
Из-за отсутствия инструкций на бумаге стали предоставлять клиенту отчёты о проделанной работе. Описывали каждое изменение: что, как, почему. Доклады стали формировать описательную часть.
Баги в проекте возникали из-за хаотичной логики и неоправданного использования странных технологий. Информация хранились в local storage, что ограничивало память до 5 МБ, приводя к переполнению и возвращению значения «null».
Система вела себя непредсказуемо – открывала данные из других разделов или не выводила на странице ничего, создавая беспричинные сюрпризы при каждом открытии.
Вызовом стало и то, что вся бизнес-логика была реализована непосредственно в базе данных. Это увеличивало скорость работы, но создавало сложности в поддержке и контроле версий:
Проект содержал уязвимости в безопасности, интеграции с сервисами не были защищены. Злоумышленники могли получить несанкционированный доступ и повредить данные. Учитывая, что в системе формируются документы строгой отчётности, это было особенно критично.
И хотя работу системы можно было поддерживать, доработка и развитие вызывали определенные риски из-за сложной архитектуры и не всегда соответствующих стандартам решений.
Возникшие трудности делали работу непростой: предстояло создать стратегию для пошагового устранения накладок и реанимирования информационного комплекса.
После года активной поддержки поняли, что развитие в текущей форме невозможно. Долгосрочное поддерживание обернулось финансовыми затратами для клиента и истощением сил команды. Мы предприняли следующие шаги, чтобы стабилизировать обстановку:
- Провели тщательный анализ состояния проекта и предложили варианты:
- сделать множество экземпляров приложения для распределения данных
- пересобрать фронтенд и доработать под него бэкенд
- переписать всё с нуля.
- С учётом сложности и ограничений, клиент согласился с предложением переделать большую часть платформы. Это позволит избежать накопления ошибок, устранять их и сэкономить на поддержке. Ведь выгоднее отдавать на плановое ТО новый автомобиль, чем не вылезать из сервиса на старой машине.
- Мы разработали детальную дорожную карту, определив этапы и контрольные точки. Клиент получил план действий и стал понимать, как будут решаться текущие проблемы.
- Создание документации и тестирование стали ключевыми этапами обеспечения качества платформы, включая подробное описание структуры, функционала и процессов работы.
- Провели аудит безопасности и внедрили меры защиты данных. Для предотвращения несанкционированного доступа укрепили интеграции с приложениями.
- Оптимизировали производительность, учитывая огромное количество параметров и интеграцию с DaData. Это позволило системе работать эффективнее и масштабироваться.
- Внедрили новые процессы разработки, включая использование современных инструментов управления проектом и систем контроля версий.
Совместно с клиентом разработали стратегию устранения инцидентов и начали воплощать в жизнь. Несмотря на сложности и объём работ, цель оставалась неизменной – построить надёжную конструкцию, которая будет служить интересам клиента на протяжении долгого времени.
В процессе работы над платформой, которая оказалась нерабочей, столкнулись с множеством вызовов. Их можно было бы решить быстрее и эффективнее, если бы проект имел руководство! Если работаете над воплощением крупных замыслов, не забывайте о фиксации производимого.
Лендинги и небольшие сайты могут обойтись без описаний работы, но не сложные системы.
Около года мы, как слепые котята, пытались найти что и как чинить и исправлять, а платформа разваливалась на глазах. В результате произошло выгорание у всех причастных, как с нашей стороны, так и со стороны клиента.
Самый главный совет, который можем дать: «Подходите к созданию проекта системно, сосредоточившись на архитектуре, безопасности и непременном создании мануалов».
Проведя большую работу, мы не просто «воскресили» веб-ресурс, но и проверили собственные процессы разработки и внедрили более эффективные правила, которые исключают возникновение подобных ситуаций. Надеемся, что опыт будет полезен, и вы не допустите таких грубых ошибок.