Polus 2.0: как пересборка архитектуры изменила разработку продукта

Мы выпустили большое обновление продукта Polus — релиз 2.0. Для пользователей это набор новых функций: штриховки, тёмная тема, печать карт, работа с мобильных устройств и расширение интеграционных возможностей системы. Но за этими функциями стоит более фундаментальное изменение, пересборка архитектуры системы. Именно она создала основу для новых пользовательских фичей и обновления внутренних процессов: подхода к дизайну и тестированию сложной логики.

Рассказываем, почему старая архитектура перестала справляться, как мы разделили систему на независимые направления и что это изменило.

Почему понадобился релиз

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

Пересборка архитектуры

Когда продукт только запускался, в Polus был простой механизм централизованного обмена слоями внутри системы: один пользователь мог вести слой, а другие подключать его к своему проекту в режиме «только для чтения». Это позволяло не дублировать данные и всегда работать с актуальной версией слоя. Для старта такого подхода было достаточно. Но по мере роста продукта и появления новых запросов от заказчиков его возможностей стало не хватать, часть задач уже было сложно реализовать в существующей архитектуре.

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

• библиотека слоёв — отвечает за повторное использование слоёв внутри системы.

• библиотека данных — отвечает за управление наборами данных, полученными из внешних систем.

• управление внешними интеграциями — отвечает за передачу данных во внешние системы.

Благодаря этому мы смогли независимо дорабатывать каждое направление и реализовать требования, которые раньше откладывались. В результате Polus стал более гибким, расширяемым и интуитивно понятным для пользователей.

Как ИИ помогал проектировать интерфейс

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

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

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

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

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

О пользовательских возможностях Polus 2.0 мы подробнее рассказали в блоге на Geometa.ru.

Если вам интересны материалы о разработке и внутренних процессах компании, поддержите нас лайком.