Публикация Школы траблшутеров

Как не надо делать логистические платформы

Время чтения: 8 мин 55 сек
10 ноября 2023 г. Просмотров: 325

Логистика, Разработка | Олег Брагинский, Виталий Лажинцев, Сергей Кондратенко

ИТ-разработка – искусство, требующее планирования, координации и технической экспертизы. Основатель «Школы траблшутеров» Олег Брагинский со слушателями школы Виталием Лажинцевым и Сергеем Кондратенко рассказывают, как спасали проект в сложных условиях.

Если заказчик меняет исполнителей, это происходит по разным причинам: от невыполнения работы до «не сошлись характерами». Одна из самых запутанных ситуаций для новой команды – исправление «нерабочего» замысла. Так и хочется спросить: «Почему бы просто не начать с нуля?»

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

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

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

«Изюминка» – внутренний умный документооборот, формирующий все необходимые шаблоны: договор и талон заявки, путевой лист, товарно-транспортная накладную и акт сверки.

Это обеспечивает юридическую прозрачность и эффективное управление перевозками, что отличает платформу от конкурентов, где такой функционал отсутствует или реализован частично:

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

Никто не исправлял возникающие проблемы, разработчики находили постоянные отговорки: «У нас всё работает» или «Починить нельзя». Баги копились, недовольство росло:

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

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

  1. Активное использование площадки. Отключение «неработающей» части ведёт к потере денег владельцев портала и пользователей приложения.
  2. Нужны внешние финансовые источники на новую разработку.

Встала задача по быстрому исправлению технических и функциональных нестыковок. Как сказал один из наших разработчиков: «Похоже на гигантскую паутину, связанную с подобной. Не паук создаёт новый блок, а сеть сама это делает – всё настолько автоматизировано».

И тут мы поняли, что починить замысел – задача второстепенная. Приоритетом стало разобраться в имеющемся функционале. Но в чём загвоздка, спросите вы? Открываете описание и готово!

Нас поджидал главный сюрприз – документации нет! Вы пробовали разбирать чужой проект без зафиксированных ожиданий и параметров функционирования? Теперь мы в этом профи.

Код представлял из себя «свалку»: предыдущая команда выбрала определенный паттерн программирования, но не стала строго следовать ему. Это не всегда проблема квалификации, а, скорее, следствие отсутствия дисциплины и организованности в работе.

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

Множество зависимостей между компонентами создавало риск поломок при изменениях и замедляло процесс исправлений, вызывая непредсказуемые осложнения:

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

Из-за отсутствия инструкций на бумаге стали предоставлять клиенту отчёты о проделанной работе. Описывали каждое изменение: что, как, почему. Доклады стали формировать описательную часть.

Баги в проекте возникали из-за хаотичной логики и неоправданного использования странных технологий. Информация хранились в local storage, что ограничивало память до 5 МБ, приводя к переполнению и возвращению значения «null».

Система вела себя непредсказуемо – открывала данные из других разделов или не выводила на странице ничего, создавая беспричинные сюрпризы при каждом открытии.

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

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

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

Возникшие трудности делали работу непростой: предстояло создать стратегию для пошагового устранения накладок и реанимирования информационного комплекса.

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

  1. Провели тщательный анализ состояния проекта и предложили варианты:
  • сделать множество экземпляров приложения для распределения данных
  • пересобрать фронтенд и доработать под него бэкенд
  • переписать всё с нуля.
  1. С учётом сложности и ограничений, клиент согласился с предложением переделать большую часть платформы. Это позволит избежать накопления ошибок, устранять их и сэкономить на поддержке. Ведь выгоднее отдавать на плановое ТО новый автомобиль, чем не вылезать из сервиса на старой машине.
  2. Мы разработали детальную дорожную карту, определив этапы и контрольные точки. Клиент получил план действий и стал понимать, как будут решаться текущие проблемы.
  3. Создание документации и тестирование стали ключевыми этапами обеспечения качества платформы, включая подробное описание структуры, функционала и процессов работы.
  4. Провели аудит безопасности и внедрили меры защиты данных. Для предотвращения несанкционированного доступа укрепили интеграции с приложениями.
  5. Оптимизировали производительность, учитывая огромное количество параметров и интеграцию с DaData. Это позволило системе работать эффективнее и масштабироваться.
  6. Внедрили новые процессы разработки, включая использование современных инструментов управления проектом и систем контроля версий.

Совместно с клиентом разработали стратегию устранения инцидентов и начали воплощать в жизнь. Несмотря на сложности и объём работ, цель оставалась неизменной – построить надёжную конструкцию, которая будет служить интересам клиента на протяжении долгого времени.

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

Лендинги и небольшие сайты могут обойтись без описаний работы, но не сложные системы.

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

Самый главный совет, который можем дать: «Подходите к созданию проекта системно, сосредоточившись на архитектуре, безопасности и непременном создании мануалов».

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