Хаос в разработке веб-сервиса — это провал. Как мы спасли криптопроект заказчика и запустили MVP за 3 месяца

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

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

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

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

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

Хоть мы и не начинали разработку веб-сервиса с нуля, процесс растянулся на несколько этапов. Вот что сделали в первой итерации ↓

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

В команде клиента не было человека, который отвечал бы за то, как должен выглядеть конечный продукт с технической стороны. Заказчик выбрал референс — Camelot DEX, но еще нужно проработать техтребования для команды, которая будет делать подобный проект.

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

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

Когда клиент обратился к нам, в первую очередь мы подключили к работе команду с проектным менеджером. После обзора готовых материалов собрали эти данные, показали их заказчику и уточнили, что от нас требуется. В итоге решили делать самую распространенную версию DEX V2, которая создана на основе протокола Uniswap v2.

Исправили и доработали смарт-контракты. Изначально мы взялись только за фронтенд и разрабатывали функционал продукта. На старте проекта нам не хватало много деталей — например, информации о том, как рассчитываются цены в долларах, показатели TVL и APR для конкретного протокола. Чтобы восполнить пробелы, мы обращались к документации Camelot DEX и Uniswap.

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

Наш solidity-разработчик реорганизовал кодовую базу и выполнил правильный деплой скриптов, чтобы сохранить версии компиляторов и библиотек, под которые изначально написаны смарт-контракты. Они были подогнаны под последнюю версию, а оставлять код в таком виде небезопасно: это сделало бы веб-сервис уязвимым к взлому.

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

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

Сверстали UI. Изначально заказчик пришел с готовым дизайном и частичной версткой, но в процессе работы изменились требования и объем работ. Из-за этого команде пришлось делать UI полностью с нуля, и из первоначального фронтенда мы по итогу ничего не использовали.

В конце первого этапа интегрировали фронт и смарт-контракты и отправили демку заказчику.

Клиент хотел, чтобы у веб-сервиса была бóльшая масштабируемость, более быстрая скорость транзакций и повышенная безопасность платформы при более низких затратах. Именно поэтому после релиза проекта на Scroll заказчик решил перенести проект в другую сеть — ZKSync. Это решение второго уровня для Ethereum.

Для перехода в новую сеть мы согласовали новые требования по смарт-контрактам. На втором круге разработки у нас уже не было техзадания, и команда использовала только документацию Camelot DEX. Нам понадобилось около недели, чтобы изучить ее и проработать перенос проекта на ZKSync.

В отличие от Scroll блокчейн ZKSync не так хорошо совместим с Ethereum из-за своей архитектуры. В частности, в этой сети по-другому вычисляются адреса пар, поэтому нам пришлось адаптировать код.

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

Во второй итерации мы также разрабатывали функционал стейкинга для провайдеров ликвидности. За основу взяли документацию Camelot DEX, чтобы разобраться с распределением токенов между пулами и рассчитать необходимые данные. В конце сверстали UI, интегрировали сабграф со смарт-контрактами и отправили заказчику демку.

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

Из-за того, что мы перенесли проект на Base, нам пришлось снова изменить настройки сабграфа. В отличие от ZKSync Base хорошо совместим с Ethereum, поэтому мы также сделали передеплой контрактов для двух блокчейнов — тестнет и мейннет.

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

Мы довели проект до готового MVP с функционалом обмена токенов и добавлением пулов ликвидности, а также решили другие задачи клиента:

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

Над проектом работали пять человек: проектный менеджер, два фронтенд-разработчика и два разработчика смарт-контрактов. В этом составе мы завершили проект за три месяца с небольшим перерывом.

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

Мы заменили клиенту фрилансеров без руководителя полноценной командой разработки на аутсорсе. Это ускорило процесс создания продукта и оптимизировало его качество. В итоге заказчик получил MVP, готовый к релизу.

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

Telegram-канал | Наш сайт