Первая Форма — полезные статьи и обновления системы

BDUI: гайд по трендовому подходу к созданию корпоративных приложений

Полезные статьи
Backend Driven UI#nbsp;— это парадигма разработки приложений, где#nbsp;сервер отвечает и#nbsp;за#nbsp;данные, и#nbsp;за#nbsp;вёрстку пользовательских интерфейсов. Она позволяет внедрять новые функции в#nbsp;режиме онлайн, без перезапусков и#nbsp;обновлений.
Меня зовут Алексей Матвеев, я#nbsp;директор по#nbsp;мобильным технологиям в#nbsp;«Первой Форме», проектирую мобильные решения около 15 лет.
Мы#nbsp;уже давно работаем в#nbsp;рамках BDUI-подхода: в частности, на#nbsp;нём построена наша мобильная платформа, которая легла в#nbsp;основу супераппа для экосистемы «Сколково».
В#nbsp;статье#nbsp;я#nbsp;расскажу о#nbsp;ключевых аспектах концепции и#nbsp;оценю её#nbsp;пользу для создания корпоративных приложений.

Навигация по материалу:

Краткая история архитектуры корпоративных приложений

Эта глава о#nbsp;том, как трансформировалась мобильная разработка с#nbsp;годами. Если вы#nbsp;уже знаете эту историю, переходите к следующим главам.
Изначально, в#nbsp;эпоху первичного глобального вэба, отдельного фронта как такового не#nbsp;было. За#nbsp;логику и#nbsp;дизайн целиком отвечал бэк, который объединял данные и#nbsp;вёрстку экранов и#nbsp;посылал на#nbsp;фронт, в#nbsp;браузер. Там и#nbsp;происходила безусловная отрисовка очередного экрана «as#nbsp;is».
Затем на#nbsp;фронте стал активно использоваться#nbsp;JS для локальных изменений контента прямо в#nbsp;браузере. Часть бизнес-логики и#nbsp;изменений интерфейса стала динамической, но#nbsp;экраны в#nbsp;целом по-прежнему собирались на#nbsp;сервере.
Потом пришла эпоха нативных мобильных приложений под iOS и#nbsp;Android#nbsp;— она полноценно разделила вёрстку (интерфейс) и#nbsp;данные, получаемые через API. Экраны уже формировались на#nbsp;уровне приложения, но#nbsp;существенная часть динамики интерфейса и#nbsp;логики обработки данных фиксировалась на#nbsp;момент сборки очередного релиза.
Логика построения нативных приложений безусловно повлияла на#nbsp;развитие вэб-приложений. Так, появились PWA-приложения, которые фактически повторяют архитектуру нативных, используя JS-фреймворки (AngularJS или ReactJS).
Затем в#nbsp;процессе унификации появилась кросс-платформенная разработка, где всё пишется на#nbsp;одном языке, а#nbsp;затем под каждую платформу собирается отдельное приложение. Это в#nbsp;корне отличается от#nbsp;простого «заворачивания» вэб-приложения в#nbsp;нативный каркас.
Эти подходы тоже накладывали ограничения на#nbsp;структуру приложений, их#nbsp;адаптивность и#nbsp;вариативность. Любое существенное изменение логики и#nbsp;дизайна требовало труда разработчиков и#nbsp;выпуска нового релиза. При этом оставался риск, что часть пользователей может забыть обновить приложение и, в#nbsp;случае с#nbsp;корпоративными системами, выпасть из#nbsp;новых бизнес-процессов.
Вот здесь-то и#nbsp;произошла смена парадигмы#nbsp;— появилась концепция Backend-Driven#nbsp;UI (или Server-Driven UI), коротко#nbsp;— BDUI.

Что такое BDUI и почему он в тренде

BDUI#nbsp;— это парадигма разработки динамических приложений, где сервер управляет не#nbsp;только данными, но#nbsp;и#nbsp;вёрсткой интерфейсов и#nbsp;функциями, доступными разным ролям пользователей. Она позволяет индивидуально настраивать приложение в#nbsp;реальном времени.
В#nbsp;основе лежат четыре принципа:
  1. полная типизация всех объектов системы,
  2. управляющая дизайн-система,
  3. строгий контракт передачи структуры интерфейсов и#nbsp;бизнес-логики с#nbsp;бэка на#nbsp;фронт,
  4. версионируемое API.
Ключевую роль в#nbsp;формировании структуры данных и#nbsp;интерфейсов API играет именно фронт. Бэк становится хранилищем данных, схем, бизнес-логики, центром администрирования процессов, построенных исходя из#nbsp;потребностей фронта, который несёт основную ценность потребителю.
При этом фронт и#nbsp;бэк развиваются независимо, и#nbsp;важно следить, чтобы новый фронт был совместим со#nbsp;старым бэком, и#nbsp;наоборот.
Конечное приложение для пользователя представляет собой набор независимых модулей, доступных в#nbsp;зависимости от#nbsp;прав и#nbsp;предпочтений пользователя, а#nbsp;также задумки архитектора рабочего места на#nbsp;основе имеющегося конструктора.
Все объекты системы имеют фиксированный набор настраиваемых представлений, а#nbsp;интерфейс строится из#nbsp;виджетов#nbsp;— небольших, встраиваемых в#nbsp;разный контекст, и#nbsp;сложных комплексных. Общий дизайн приложения определяется дизайн-системой.
Фактически на#nbsp;клиенте зафиксирован только общий каркас и#nbsp;базовая логика поведения. В#nbsp;остальном он#nbsp;получает инструкции по#nbsp;работе от#nbsp;сервера и#nbsp;динамически их#nbsp;интерпретирует#nbsp;— становится «браузером» функциональных сценариев.
Интерфейс и#nbsp;возможности одного и#nbsp;того#nbsp;же приложения могут отличаться для разных групп пользователей, подразделений, компаний. При этом любой настроенный в#nbsp;рамках возможностей текущего ядра платформы процесс может быть доступен для любого пользователя.
В#nbsp;итоге, данный подход идеально подходит по#nbsp;своему духу для построения максимально гибкой и#nbsp;динамичной BPM-системы.
В нашем мобильном приложении можно реализовать любые ваши процессы

Отправьте заявку, и#nbsp;мы#nbsp;рассмотрим задачи и особенности вашей компании на#nbsp;демо-встрече
Отправить заявку
{$co}

Плюсы BDUI для бизнеса

Сегодня в#nbsp;рамках BDUI-подхода свои продукты развивают Яндекс, Авито, Тинькофф, Озон и#nbsp;прочие IT-гиганты. За#nbsp;последние годы BDUI стал самостоятельным направлением больших IT-конференций, целиком посвященных этой теме. Поэтому рассмотрим ключевые плюсы подхода в#nbsp;разрезе каждодневных потребностей высокотехнологичной компании.

Быстрая доставка новых функций с минимальными затратами

Администратор системы полностью контролирует содержимое приложения. Он#nbsp;может включать и#nbsp;отключать функции сразу всем пользователям или группам, добавлять новые шаги, условия или ветвления в#nbsp;старые процессы, а#nbsp;изменения сразу появятся у#nbsp;пользователей.
Когда по#nbsp;миру гулял коронавирус, мы#nbsp;за#nbsp;вечер построили процесс сбора данных о#nbsp;вакцинации. Уже утром важный процесс был доступен сотрудникам компании из#nbsp;любого интерфейса.

Возможность быстрых глобальных изменений

Приложение работает с#nbsp;типизированными объектами по#nbsp;чётким инструкциям, поэтому нужно только задать бизнес-логику и#nbsp;визуализацию процесса в#nbsp;админ-панели.
Перед Новым Годом нам нужно было собрать с#nbsp;сотрудников данные о#nbsp;детях для подготовки поздравлений и#nbsp;подарков. Мы#nbsp;быстро настроили и#nbsp;запустили процесс, но#nbsp;в#nbsp;спешке забыли добавить пункт анкеты про интересы ребёнка. Поле мы#nbsp;добавили в#nbsp;действующую анкету, и#nbsp;оно появились даже у#nbsp;сотрудников, которые её#nbsp;уже заполнили.

В одном приложении можно создать сколько угодно рабочих мест со своим набором функций и дизайном

Пользователь может менять роли и#nbsp;даже совмещать несколько функциональных ролей. При выдаче определенных прав он#nbsp;сразу получает новые рабочие возможности и#nbsp;интерфейс.
Мультиролевая модель реализована в#nbsp;нашем супераппе для экосистемы «Сколково». В#nbsp;общей сложности все процессы структурированы для более чем 20 ролей. Для каждой роли продуман свой сервисный дашборд.

При скачивании приложения пользователь получает базовый набор функций (гостевой режим): информационные виджеты, календарь мероприятий, общие сервисные функции (заказ такси, поиск кафе, подбор апартаментов для проживания). Как только, например, он#nbsp;арендует жильё, он#nbsp;получает роль «Житель», после чего может обращаться в#nbsp;управляющую компанию, оформлять пропуска для машин и#nbsp;ещё много чего.

Большой простор для маркетинговых, процессных и UX-исследований

BDUI позволяет тестировать различные гипотезы, быстро запускать пилотные и#nbsp;интеграционные проекты, брендировать приложение для подразделений, компаний и#nbsp;партнёров. Для этого достаточно создать новую роль и#nbsp;настроить для нее функциональную и#nbsp;визуальную части.
Пересматривая программу онбординга, мы#nbsp;выбирали, как лучше подать большой блок о#nbsp;возможностях системы: сразу погрузить новичков в#nbsp;обилие деталей или сократить информацию. Мнения в#nbsp;проектной команде разделились, и#nbsp;были запущены оба варианта в#nbsp;рамках A/B-тестирования, разделив новых пользователей на#nbsp;группы. После этого проведя интервью с#nbsp;пользователями, мы#nbsp;поняли, на#nbsp;каком из#nbsp;вариантов лучше остановиться.

Конструирование удобных интерфейсов «на лету»

Динамика BDUI помогает кастомизировать и#nbsp;адаптировать сложные (иногда весьма громоздкие) процессы, не#nbsp;потеряв в#nbsp;функциональности. Мы#nbsp;можем строить простые ролевые интерфейсы для решения конкретных задач (с#nbsp;учётом особенностей различных фронтов), избегая информационной перегрузки и#nbsp;глобальной «резиновой» вёрстки для любого фронта, соблюдая общую консистентность.
В#nbsp;качестве простейшего примера#nbsp;— постановка отсутствий в#nbsp;календарь. Интерфейсы имеют некоторые различия, исходя из#nbsp;обзорных возможностей, но#nbsp;решают одну задачу. В#nbsp;любой момент можно глобально и#nbsp;независимо изменить каждый из#nbsp;них.

Минусы BDUI

Безусловно, идеальных решений не#nbsp;бывает. BDUI накладывает ограничения: быстро, гибко и#nbsp;красиво#nbsp;— тут зачастую приходится жертвовать одним из#nbsp;трёх условий. Можно было#nbsp;бы в#nbsp;этот ряд поставить также «дёшево», но, как я#nbsp;упоминал в#nbsp;разделе плюсов, экономия ресурсов при внедрении#nbsp;— одна из#nbsp;важнейших составляющих подхода.
  • Для развития системы сложнее найти кадры. BDUI подразумевает (в#nbsp;максимальной формулировке), что фронт-разработчик получит в#nbsp;управление бэк#nbsp;— частично или полностью. Тут не#nbsp;подойдёт привычный фулстек-подход (от#nbsp;бэка к#nbsp;фронту), нужно мыслить как архитектор прикладных процессов, спускать UI/UX-концепции с#nbsp;фронта на#nbsp;бэк.
  • Типизация и#nbsp;жёсткость контактов фронта и#nbsp;бэка ограничивают возможности визуализации. Мы#nbsp;можем очень быстро запустить процесс на#nbsp;текущем конструкторе, но#nbsp;если понадобятся принципиально новые возможности, то#nbsp;придётся синхронно развивать систему. При этом принципиальные нововведения будут доступны только в#nbsp;новом релизе.
Суперапп для экосистемы «Сколково» вырос из#nbsp;потребностей пользователей, чьи дети учатся в#nbsp;Международной Гимназии. Функции были ограничены, что местами сильно упростило архитектуру и#nbsp;ускорило запуск проекта. Но#nbsp;в#nbsp;дальнейшем стали появляться новые функциональные потребности, что привело к#nbsp;необходимости выбора: делать долго с#nbsp;полной обратной совместимостью старых и#nbsp;новых релизов или перейти на#nbsp;архитектуру 2.0 с#nbsp;обязательным обновлением всех старых версий приложения для полноценной работы.

В#nbsp;ближайшем будущем мы#nbsp;готовим большое обновление приложения, почитать можно тут.
  • Нужно соблюдать баланс между многообразием возможностей и#nbsp;простотой настройки системы. Если слишком глубоко уйти в#nbsp;кастомизацию интерфейса, то#nbsp;в#nbsp;конечном счёте можно получить сложную систему, которая в#nbsp;неумелых руках администратора даст построить чрезмерно сложный процесс с#nbsp;сомнительным#nbsp;UX.
У#nbsp;нас есть клиент, чьи администраторы, пройдя наше базовое обучение, теперь сами настраивают процессы, зачастую сильно перегружая#nbsp;их. В#nbsp;результате этой избыточности может страдать быстродействие. В#nbsp;итоге решать эту проблему приходится нам либо через какие-то структурные оптимизации, либо даже через запреты на#nbsp;определённые настройки.
Философия нашей BPM-системы заключается в#nbsp;оперативном решении любых задач заказчика. Поэтому в#nbsp;зависимости от#nbsp;ситуации чаще возникает выбор между «гибко» и#nbsp;«красиво».
В#nbsp;современном мире «быстрый» чаще побеждает «умного». Скорость#nbsp;— ключевое преимущество подхода BDUI. Правда, чтобы обрести её#nbsp;без ущерба функциональности, сначала нужно пройти существенный путь становления. Вот как это было у#nbsp;нас.

Low-code на службе BDUI

«Первая Форма» занимает лидирующие позиции в#nbsp;рейтинге low-code BPM-систем на#nbsp;российском рынке. Low-code подход обеспечивает существенную гибкость и#nbsp;функциональность нашим приложениям. С#nbsp;ним любые интеграции и#nbsp;настройки процессов можно реализовать проще и#nbsp;без привлечения разработчика платформы (то#nbsp;есть существенно быстрее и#nbsp;дешевле).
Итак, что#nbsp;же под капотом мобильного приложения «Первой Формы»:
  • Функциональность iOS/Android-версий повторяет вэб, насколько позволяют размеры экранов и#nbsp;технические возможности устройств.
  • В#nbsp;базе в#nbsp;приложении есть мессенджер, аудио/видео звонки и#nbsp;ВКС, таск-трекер, работу с#nbsp;подписями, включая ЭП, календарь, почтовый клиент, распознавание документов и#nbsp;многое другое.
  • Работать можно в#nbsp;рамках различных лицензионных политик, сразу с#nbsp;нескольких учётных записей на#nbsp;разных серверах.
  • Клиент получает базовое решение, которое можно наполнить любыми процессами индивидуально для каждой роли в#nbsp;компании. На#nbsp;старте проекта этим всегда занимаемся мы, но#nbsp;в#nbsp;дальнейшем подхватить эстафету могут прошедшие у#nbsp;нас обучение администраторы со#nbsp;стороны клиента.
  • Единое приложение работает с#nbsp;in-house инсталляциями на#nbsp;серверах клиентов и#nbsp;совместимо даже с#nbsp;бэками двухлетней давности.
  • Можно выпускать независимые брендированные версии приложения по#nbsp;запросу клиента. Важно, что это не#nbsp;только повышает статус бренда в#nbsp;глазах сотрудников и#nbsp;партнёров, но#nbsp;и#nbsp;положительно влияет на#nbsp;стабильность и#nbsp;минимизирует проблемы при выходе новых версий: ключевой набор функций нового релиза можно детально перепроверить и#nbsp;решить процессные проблемы ещё до#nbsp;выпуска.

Для BDUI мы активно используем механизм динамического API и Lua-скрипты:

Платформа в#nbsp;целом типизирована, построена на#nbsp;жестких контрактах и#nbsp;имеет богатое фиксированное REST API. Тем не#nbsp;менее, при внедрении системы клиентам регулярно возникает необходимость настраивать интеграции со#nbsp;сторонними сервисами и#nbsp;прописывать кастомные сценарии поведения приложения.
Для этих задач можно в#nbsp;любой момент дополнить API динамическими запросами. Новый метод примет определённый набор данных, обработает их#nbsp;по#nbsp;нестандартной логике и#nbsp;сформирует BDUI-сценарий для отработки в#nbsp;приложении.
Являясь очень простым по#nbsp;сути, язык Lua позволяет писать real-time сценарии работы с#nbsp;прямым доступом к#nbsp;данным системы. Он#nbsp;отлично подходит для быстрого написания сложных логических сценариев обработки данных и#nbsp;позволяет на#nbsp;лету формировать JSON-ответы. Альтернативы, конечно, есть, но#nbsp;тот#nbsp;же SQL-подход на#nbsp;практике оказывается более громоздким и#nbsp;предъявляет повышенные требования к#nbsp;квалификации разработчика.
Предположим, есть сторонний сервис новостей, а#nbsp;мы#nbsp;не хотим делать полноценную затратную интеграцию, заводить процесс и#nbsp;все сущности для синхронизации в#nbsp;нашей базе данных и#nbsp;так далее. Тогда мы#nbsp;делаем простое прокси-решение:

  1. Публикуем новый метод для получения ленты новостей.
  2. Под капотом на#nbsp;Lua формируем сетевой запрос к#nbsp;стороннему сервису, обрабатываем полученные данные, формируем необходимую типизированную отдачу.
  3. Через админ-панель приложения настраиваем новый виджет новостей на#nbsp;базе нового метода.

Всё! При открытии приложения пользователь видит новости из#nbsp;стороннего сервиса.

Химия между BDUI и low-code

Любая система-конструктор строится на#nbsp;базовых сущностях. И#nbsp;при решении любой нестандартной задачи возникает вопрос: расширять#nbsp;ли текущий набор сущностей или на#nbsp;прикладном уровне воспользоваться такими парадигмами, как протокол, адаптер или даже «вью-модель». Мы#nbsp;пошли вторым путём.
Зачастую данные совершенно разной природы можно и#nbsp;даже нужно представить в#nbsp;едином виде. Но#nbsp;случается и#nbsp;обратная задача#nbsp;— создать разные представления одной и#nbsp;той#nbsp;же сущности.
В#nbsp;нашей системе есть набор статических и#nbsp;параметрических представлений данных. Мы#nbsp;используем их#nbsp;в#nbsp;разных контекстах: список, агрегация, создание и#nbsp;показ сущности. Конечный вид зависит от#nbsp;процесса и#nbsp;от#nbsp;пользователя, который в#nbsp;нём работает.
Например, в#nbsp;виде списка можно показать:
  • компании на#nbsp;основе данных CRM,
  • коллег, у#nbsp;которых скоро день рождения,
  • платёжные поручения из#nbsp;внешней системы.
В#nbsp;первом случае мы#nbsp;используем типовую архитектуру системы и#nbsp;через API передаём список базовых сущностей («задач») из#nbsp;модуля CRM.
Во#nbsp;втором мы#nbsp;работаем со#nbsp;списком сущностей типа «пользователь». Для получения есть отдельный метод API, но#nbsp;стандартное представление, очевидно, другое. Поэтому мы#nbsp;добавляем на#nbsp;лету новый метод API, который содержит Lua-адаптер для представления данных сущности «пользователь» в#nbsp;виде «задачи». В#nbsp;итоге мы#nbsp;получаем адаптивную модель данных для показа в#nbsp;нужном представлении.
Приложению при этом совершенно не#nbsp;важно, какой метод API вызывать для решения задачи. Ключевой момент, что оно получило понятную структуру данных и#nbsp;представлений, достаточную для безошибочной интерпретации и#nbsp;визуализации. Дополнительно мы#nbsp;можем переопределять и#nbsp;взаимодействие пользователя с#nbsp;полученным контентом.
Третья задача похожа на#nbsp;вторую. Но#nbsp;здесь мы#nbsp;дополнительно осуществляем интеграцию с#nbsp;внешней системой, из#nbsp;которой Lua-скрипт должен сначала получить исходные данные, после «переупаковать» их#nbsp;по#nbsp;правилам системы и#nbsp;сформировать JSON ответ. И#nbsp;это всё без настройки сложной интеграции между системами.

Любая клиентская потребность как часть платформы: кейс «Спортмастер»

В#nbsp;качестве примера расскажу, как мы#nbsp;по#nbsp;запросу «Спортмастера» внедряли функцию «Чек-лист». Была поставлена задача построить процесс проверки готовности торговых залов к#nbsp;работе с#nbsp;фиксацией недостатков и#nbsp;постановкой поручений по#nbsp;их#nbsp;исправлению.
В#nbsp;самом простом случае, без зависимостей и#nbsp;ветвлений, чек-лист можно представить как таблицу Excel, где в#nbsp;каждой строчке с#nbsp;вопросом мы#nbsp;можем добавить ответ, комментарии, приложить какие-то подтверждающие файлы. Так мы#nbsp;реализовали параметрическое представление чек-листа на#nbsp;основе базовой сущности «таблица».
Из#nbsp;API-запроса клиент получает информацию о#nbsp;визуальной интерпретации приходящих данных#nbsp;— должна#nbsp;ли это быть просто таблица для заполнения, или это технологичный чек-лист с#nbsp;удобным интерфейсом.
Все данные находятся в#nbsp;системе, и#nbsp;благодаря low-code настройкам клиент может прямо по#nbsp;ходу заполнения чек-листа запускать смежные процессы: например, автоматически поставить задачу специалистам хозяйственной службы на#nbsp;уборку зала.
В#nbsp;итоге любой процесс в#nbsp;системе можно обогатить функциональностью чек-лист несложными настройками на#nbsp;сервере.
Например, у#nbsp;нашего отдела продаж, тоже есть свой чек-лист, для подготовки ко#nbsp;встрече с#nbsp;клиентом. Менеджеры вносят в#nbsp;него текущие потребности и#nbsp;особенности клиента, а#nbsp;по#nbsp;результатам заполнения запускаются связанные процессы на#nbsp;основе собранных данных.
У#nbsp;нас ещё много кейсов со#nbsp;«Спортмастером» и#nbsp;другими крупными компаниями

Для некоторых, например, для «Вкусвилла», мы#nbsp;настраивали особый процесс с#nbsp;участием выездных сотрудников. Этот и#nbsp;другие кейсы мы#nbsp;собрали в#nbsp;отдельном разделе.
Перейти
{$co}

Суперапп SkolCity

Как я#nbsp;уже рассказывал, несколько лет назад к#nbsp;нам пришёл запрос на#nbsp;автоматизацию процессов Международной Гимназии «Сколково» и#nbsp;создание мобильного приложения, которое объединило#nbsp;бы учителей, родителей и#nbsp;различные службы гимназии. Фактически нужно было запустить внутренний мобильный портал, включающий соцсеть для участников и#nbsp;набор внутренних административных сервисов.
Установочная встреча прошла в#nbsp;июле, а#nbsp;уже 1#nbsp;сентября мы#nbsp;выпустили первую версию приложения SkolCity, в#nbsp;котором оцифровали ключевые процессы Гимназии. Со#nbsp;временем их#nbsp;количество существенно выросло, например, мы#nbsp;добавили:
  • чаты для общения родителей и#nbsp;учителей по#nbsp;классам, частых вопросов, консультаций с#nbsp;тьютором и#nbsp;психологом;
  • новости и#nbsp;календарь мероприятий;
  • информацию по#nbsp;дополнительному образованию и#nbsp;возможность записаться в#nbsp;секции;
  • формирование платежных поручений за#nbsp;обучение;
  • личный кабинет родителя, где можно управлять профилями детей, заказывать справки, проверять льготы и#nbsp;управлять списком доверенных лиц;
  • журнал контроля посещаемости по#nbsp;пропускам и#nbsp;многое другое.
Вскоре подключиться к#nbsp;приложению захотели и#nbsp;другие подразделения «Сколково». Сегодня им#nbsp;пользуются сотрудники Технопарка, арендаторы жилья, центральная диспетчерская, эксперты Фонда и#nbsp;даже его вице-президент. Многие при этом имеют доступ к#nbsp;нескольким функциональным блокам супераппа, так как снимают апартаменты, работают в#nbsp;Технопарке, а#nbsp;их#nbsp;дети обучаются в#nbsp;Гимназии.
Кейсы обо всех функциях SkolCity мы#nbsp;собрали в#nbsp;отдельную подборку
Читать
{$co}

Искать ли альтернативу BDUI или «лучшее — враг хорошего»?

Основные принципы современного IT-подхода#nbsp;— делать быстро, экономично, гибко, с#nbsp;возможностью переиспользовать результаты. Чем больше типовой работы можно сделать без участия разработчика, тем лучше. И#nbsp;в#nbsp;этом плане подход BDUI отлично зарекомендовал себя. Недаром все крупные компании активно развивают свои практики и#nbsp;регулярно делятся друг с#nbsp;другом достижениями на#nbsp;профильных конференциях.
Но#nbsp;это, конечно, не#nbsp;означает, что любое приложение нужно априори строить на#nbsp;этих принципах. Экономическая составляющая архитектуры проекта очень важна, а#nbsp;также многое зависит от#nbsp;класса решаемых задач.
В#nbsp;любом случае, важно вовремя переориентировать проект в#nbsp;BDUI-направлении. Мне кажется, что уже не#nbsp;за#nbsp;горами его интенсивное развитие, и#nbsp;потому пора минимизировать подходы уровня «copy/paste» и#nbsp;«monkey job».