БДУИ или как мы решали одну проблему, а получили 10 другихРебята из Авито
в этой статье поделились описанием их реализации Backend-driven UI.
Так как у меня уже был опыт работы с такими вещами в одной поисковой компании, решил оставить комментарий на этот счет.
Какую проблему решали в Авито, по версии автора статьи:
- для решения самых тривиальных задач требуется привлечение квалифицированных кадров;
- команда может быть загружена более приоритетными фичами;
- изменения до каждой платформы доедут в разное время.
Перевожу:
- Менеджеры хотят рулить интерфейсом самостоятельно
- Инженеров мало и их фокус нужно сохранять на том, что считается более приоритетным
- Хочется обновляться на входе в приложение, а не когда юзер обновится из стора
Их подход к решению, в целом, аналогичен другим таким же решениям: есть бекенд который хранит JSON с мета-описанием интерфейса, куда умудряются запихнуть описания всех возможных состояний для всех элементов в bdui макете. На выходе получается огромная нечитаемая портянка, которую-то и в ручную не собрать, поэтому команда разработчиков прикручивает к этому всему web-конструктор, в котором можно предварительно посмотреть результат, провалидировать и сгенерировать выходной JSON. Далее он отправляется в бекенд-сервис для раздачи пользователям.
Классно же звучит, не так ли? Кажется, все проблемы решены.
Но не будем радоваться раньше времени. Вот список вытекающих из этого следствий:
- Обучение людей работе с конструктором. Так как внутренние решения не блещут отлаженностью, есть масса нюансов, которые знают кодеры, но очень туго воспринимают менеджеры.
- Бесконечные тикеты на апдейты конструктора и добавление новых фич в БДУИ
- Менеджеры стремятся абстрагивать всё что можно от программистов, в итоге на bdui переезжает столько интерфейса сколько возможно
- Создается отделый цикл релиза, контроля и тестирования где программист уже не имеет необходимого контекста, но должен присутствовать ибо менеджеры всё еще не знают всех нюансов - в итоге упускается масса проблем уходящих в продакшн.
- Менеджеры накручивают А/Б тесты, виджеты интерфейса под сложными условиями отображения, в итоге не ясно какой интерфейс видит пользователь
И самая большая проблема, от которой бежали, но в которую напоролись: BDUI также развивается как любой продукт, который надо обновлять. Его инфраструктура обновляется через сторы: фиксятся баги, добавляются фичи. Через какое-то время возникает чудовищная фрагментация возможностей фреймворка на девайсах юзеров. А JSON-то общий! Как для любого API приходится вводить фолбеки и версионирование. На практике же логгеры сыплют ошибками парсинга, интерфейс на глазах у юзера моргает и откатывается к дефолтному, написанному руками без всяких bdui, ну или к предыдущему стабильному макету, а это уже, напомню, возврат к третьей проблеме доставки фич в разное время.
Но теперь всем не скучно: метрики обогащаются ростом ошибок, беклоги срочными фиксами, менеджеры занимаются тем, что умеют лучше всего - находить решения из «сложившейся ситуации».
BDUI, кто бы его не начал пилить, всегда лежит между нативом и кроссплатформой, вроде React Native, который, к слову, решает те же проблемы примерно тем же подходом. Но вместо объединения преимуществ, объединяются недостатки:
- Новый уровень абстракции и сложности в коде
- Новые процессы и люди там где их раньше не было
- Обновления через сторы не обойти
- Ухудшение стабильности и пользовательского опыта
- Энтропия ранее понятного и оттестированного нативного решения.
- Разработчики фреймворка становятся носителями уникальной экспертизы и создают риски в случае увольнения.
Как говорится, не хотели привлекать 1 разраба для решения тривиальных задач, теперь нужно 10, чтобы решать нетривиальные.
Напомню, что ios приложение Telegram практически полностью написал 1 человек. Это недостижимый уровень доверия и менеджмента, на который многие известные компании просто неспособны. Отсюда и БДУИ.
