Разработка приложений со 100%-й кастомизацией. Customization Driven Development (CDD) / Хабр | Веб-студия Nat.od.ua
Разработка приложений со 100%-й кастомизацией. Customization Driven Development (CDD) / Хабр
В данной статье я хочу поделиться своим опытом разработки интерфейсов с уровнем кастомизации вплоть до 100% (реальные 100%). При этом сохраняется обратная совместимость и возможность апдейтов. Магия? — Нет, это CDD!
Все началось еще в 2018 году в одной крупной международной компании. Меня пригласили в главный офис для объяснения топ руководству как мы будем решать проблему кастомизации нашего продукта, а конкретно UI части. Клиентам необходимо было немного изменить его под себя и кое-что добавить. Нужно было сохранить обратную совместимость, чтобы клиенты могли получать обновления продукта. Тогда я знал только про возможности добавления “дыр” в коде (slots), в которые можно добавить любой функционал. Ну еще и про API, уже для изменения функциональности. Понятно что ни о какой возможности кастомизации на все 100% речи не шло, ведь тогда нужно изменять исходный код, а это само собой потеря обратной совместимости.
Конечно CDD нужен далеко не всем. Эта техника будет крайне полезна при разработке продукта, клиентам которого необходима глубокая кастомизация. Я имею ввиду, не просто поменять логотип и название, а поменять абсолютно все что душе угодно. И при этом не потерять возможность будущих апдейтов продукта.
Как же добиться практически 100%-й кастомизации и без единого разрыва без потери обратной совместимости?
В CDD используется «декларативная кастомизация», т.е. все представление с логикой должны быть вывернуты наружу для возможности полной кастомизации. Если необходимо кастомизировать определенные части довольно сложной компоненты, тогда мы просто отображаем ее более простые внутренние компоненты. Эти компоненты могут быть упакованы в так называемый “черный ящик” с богатым API и “дырами” (slots), либо также отображены еще более простыми компонентами. Представление с логикой любых компонент (кроме примитивных) всегда можно вывернуть наружу, для получения 100% доступа.
И здесь вы можете возразить: “Но как же, ведь когда мы используем внутреннее содержимое, тогда мы теряем возможность апдейтов!”. Нет, это не совсем так, и вот почему:
-
Компонента любой сложности (кроме примитивной) — это всего лишь набор более простых компонент, который всегда есть в свободном доступе и при ее апдейте, мы наглядно видим что и где в этом наборе изменилось и можем очень просто и быстро проапдейтить ее вручную (если это нужно);
-
Сложная компонента состоит из менее сложных компонент, которые мы можем оставить в их стандартном, упакованном виде, если нам не нужна их глубокая кастомизация и естественно будем получать их апдейты автоматически;
Хорошо. А как же этого добиться? Какие шаги?
Сначала нужно разработать самые примитивные компоненты. Они могут, а некоторые из них даже должны иметь по 2 варианта:
-
Стандартный компонент, “черный ящик” с богатым API и “дырами” (slots), удобен в использовании, но имеет ограниченные возможности кастомизации ;
-
Компонент-обертка, расширяет возможности контента, который вы сами помещаете внутрь. Менее удобен в использовании, но имеет гораздо большие возможности кастомизации, вплоть до 100%. Обязательно для стандартных HTML элементов: