Большое мышление и выбор архитектуры внешнего интерфейса

проблема

«Одно облако и несколько терминалов» стали тенденцией, и типов терминалов становится все больше. Например, теперь продукты веб-сайта ПК уже доступны, и теперь я хочу расширить приложение, маленькое
Процедура... как сделать? Метод, который можно непосредственно представить, заключается в добавлении интерфейса API к APP и т. д. на основе оригинала, как показано на следующем рисунке:

image.png

Это можно сделать, но как только вы столкнетесь с модификациями, очень хлопотно и не идеально изменять код нескольких концов одновременно.

«Разделение передней и задней части» стало тенденцией. Вначале большинство веб-сайтов для ПК использовали модель внешней и внутренней интеграции рендеринга на стороне сервера. С развитием технологий интерфейс и сервер отделяются, и внешний рендеринг постепенно становится тенденцией. Соответственно, фронтенд-разработчики также независимы от бэкэнд-команды.
Недавно появившиеся приложения, небольшие программы и т. д. по своей сути отделены от передней и задней части.
Front-end, APP, апплет и т. д. независимы друг от друга в выделенных командах, которые, конечно, могут соответствовать этой тенденции.
Соответственно сервер должен предоставлять сервисы для каждого front-end отдела.На практике часто встречается много повторяющегося контента.Есть ли способ увеличить повторное использование? Или back-end может подключаться только к одному «большому front-end» отделу, а остальная часть «большого front-end» отдела может решить эту проблему сама?

image.png
Интерфейс API, разработанный сервером, предназначен для общих служб или пользовательского интерфейса? У каждого терминала разные требования к отображению данных, должны ли они предоставляться общедоступному API или разным API?
Например, для отображения времени на стороне ПК может потребоваться формат «2018-6-11», а на стороне приложения может потребоваться формат «2018/6/11».Как обеспечить интерфейс?
Другой пример: для интерфейса с той же функцией требуется 20 полей на веб-странице ПК, что и было сделано. Из-за небольшого размера экрана приложения достаточно полей 10. Должны ли мы повторно использовать старый API, чтобы приложение могло выдерживать спам, или добавить дополнительный интерфейс к приложению?
Сторонники интерфейса и сервера могут иметь разные мнения, что приводит к конфликту. У каждого есть определенная причина, как согласовать?
Менеджер по продукту предложил PRD-"Черновик взаимодействия дизайна UED-"интерфейс дизайна пользовательского интерфейса-"интерфейс API-интерфейса внутреннего интерфейса-"служба реализации внутреннего интерфейса-" совместная отладка внешнего и внутреннего интерфейса... Вышеприведенное является общим процесс разработки, весь процесс по-прежнему относительно долго. После фронтенд-разработки статической страницы часто нужно дождаться разработки бэкэнд-сервиса перед совместной отладкой, что часто приводит к пустой трате времени. Когда фоновое обслуживание завершено, часто приближается время испытаний, и атмосфера очень напряженная. Весь опыт разработки часто представляет собой «наполовину морскую воду, наполовину огонь». Есть ли способ сократить этот процесс и позволить внешнему интерфейсу завершить разработку самостоятельно, не полагаясь на завершение фоновой службы?

Архитектура

Исходя из текущей ситуации, после того, как внешний и внутренний интерфейсы разделены, сервер может напрямую предоставлять услуги различным терминалам. Преимущество этого метода в том, что он прост и понятен, а недостаток в том, что он недостаточно гибок. Поэтому рассмотрите возможность вставки промежуточного слоя между интерфейсом и сервером в качестве моста между интерфейсом и сервером для дополнительной гибкости. Что касается имени этого среднего уровня, то это «уровень шлюза или уровень доступа», который можно спутать с существующим уровнем шлюза и доступа в фоновом режиме. Другое название называется BFF (Backend for Frontends), что является относительно точным и не вызовет путаницы.

Уровень шлюза или уровень доступа

image.png

BFF (Backend for Frontends, серверная часть, существующая для внешнего интерфейса)

image.png

Решение

Для «одного облака и нескольких терминалов» адаптация может быть выполнена на уровне BFF. Можно рассматривать режим MVVM, данные с сервера рассматриваются как Модель, а в BFF для разных терминалов предусмотрены разные ViewModels. Если данные меняются, просто измените Model. Если вы хотите добавить сторону, просто добавьте к ней ViewModel. Централизованная модификация здесь может освободить работу по преобразованию форматов для каждого терминала.
После «разделения передней и задней частей» различные стороны могут быть объединены в «большую переднюю часть», а окно, которое общается с задней частью, называется BFF. Что касается серверной части, то, если требования к данным BFF выполняются, «большой интерфейс» может справиться с остальными самостоятельно.

image.png

Интерфейс API, разработанный сервером, ориентирован на общие службы и не должен быть ориентирован на пользовательский интерфейс. Различия пользовательского интерфейса различных терминалов адаптируются на уровне BFF. Таким образом, серверная часть может быть больше сосредоточена на бизнес-логике и службах данных, не беспокоясь о различиях между различными концами.
Весь процесс разработки слишком долгий, что приводит к взаимному ожиданию и тратам. В ответ на эту проблему мы можем рассмотреть возможность разделения процесса разработки на две части на уровне BFF. Как независимый отдел разработки, «большой интерфейс» опережает серверную часть на один цикл выпуска версии. Конкретный метод заключается в том, что для новых сервисов фиктивные данные генерируются на уровне BFF.Для различных терминалов это эквивалентно готовности серверной службы, и совместная отладка может выполняться напрямую, без ожидания. Таким образом устраняется зависимость данных внешнего интерфейса от внутреннего, что делает его более гибким.

организационная структура

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

Идеи классификации

«Большой интерфейс» предназначен для всей задней части, поэтому этот слой разделен по функциям.
Под "большим передком" он еще разделен по функциям? Например, разработка iOS, разработка Android, разработка H5 и так далее. Такой метод деления осуществим, но польза от него не очень велика. Это всего лишь «объединение» небольших отделов в относительно большой отдел, причем степень интеграции не очень высока. Другой метод разделения с более высокой степенью интеграции состоит в том, чтобы разделить его на два подотдела «базового обслуживания» и «развития бизнеса» в рамках «большого фронтенда».

image.png

Основной обязанностью «базовой службы» является предоставление государственных услуг, государственных компонентов, периферийных объектов и т. д. для всего сектора «большого фронта». В соответствии с потребностями и реальной ситуацией его можно разделить на «архитектуру», «инструменты», «компоненты» и другие группы.
Основной обязанностью «Развития бизнеса» является удовлетворение потребностей бизнес-единицы. В соответствии с развитием бизнеса, группа делится в зависимости от конкретного бизнеса.

Состав персонала

Персонал по-прежнему ищут с точки зрения профессионального разделения труда.Согласно идее не менее 2 человек в каждой роли для предотвращения одноточечных рисков, требования к персоналу следующие:
iOS-разработка: 2 человека
Android-разработка: 2 человека
Разработка H5: 4 человека
Разработка Node или Java (BFF): 2 человека

управлять

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

функциональное управление

«Большой фронтенд» разделен по функциям, соответствующим бэкенду.

Гибкое управление

«Большой интерфейс» в основном сгруппирован по бизнесу, и благодаря внедрению BFF внутри «большого интерфейса» может быть сформирован замкнутый цикл разработки, и можно рассмотреть гибкое управление.
Для реализации гибкого управления требуется поддержка продукта и тестирования. В соответствии с бизнесом связанные продукты, дизайн, тестирование, разработка («большой интерфейс») формируются в виртуальные команды.

Процесс

В соответствии с моделью управления используется комбинация водопадной модели и гибкой модели.

модель водопада

Для функциональных организаций подходит процесс разработки с использованием модели водопада. Отдел продукта, технологический отдел и отдел тестирования, как правило, тесно связаны с разработкой продукта и связаны в соответствии с моделью водопада. Учитывая режим разработки с разделением интерфейса и сервера, «большой интерфейс» может самостоятельно завершить разработку с обратной связью, хотя данные уровня BFF имитируются. Кроме того, для разработки большой клиентской версии требуется более одной версии перед серверной частью, что также облегчает тестирование серверных служб. Проще говоря, это означает изменить обычный «тип push-функции бэкенда» на «тип вытягивания большого внешнего продукта».

PRD продукта — «Взаимодействие/Дизайн пользовательского интерфейса» — «Разработка крупного интерфейса — «Большое тестирование интерфейса —» Внутренний релиз крупного интерфейса
Back-end разработка сервиса - "back-end тестирование" - "стыковка" с соответствующей версией front-end (в основном работа BFF, Mock data изменена на выборку данных из back-end сервиса) - "предрелизная среда проверка -" продукт онлайн

Гибкая модель

Продукты, тесты и большие интерфейсы можно считать совместными и разрабатывать в соответствии с agile-моделью. Цель состоит в том, чтобы сломать стену отдела и укрепить связь; сделать развитие бизнеса общей целью для формирования совместной силы.

Цикл разработки составляет 4 недели и распределяется в соответствии с соотношением 1 неделя предварительного исследования, 2 недели разработки и тестирования и 1 неделя реконструкции.
1 неделя перед исследованием:Основная задача этой недели — полностью рассказать о продуктах, тестировании и разработке, а также достичь консенсуса по бизнес-целям на этот период.
Основная работа продукта заключается в том, чтобы объяснить требования, прототипы и проекты, описать их в сценариях, установить приоритеты и обеспечить правильное понимание членами команды текущего бизнеса.
Основная работа по тестированию заключается в написании тестовых случаев, просмотре вариантов использования и, наконец, формировании исполняемых фиктивных данных на уровне BFF с помощью соответствующих инструментов.
Основная работа по разработке заключается в проведении предварительного исследования технологии, выборе технологии, разработке технологии, распределении задач, оценке работы и т. д. в соответствии с потребностями бизнеса. Выполните то, что требуется на «совещании по планированию», чтобы назначить людям задачи по развитию.
2 недели разработки:Разрабатываем по agile модели и внедряем бизнес. «Ежедневное постоянное собрание» должно проводиться последовательно и своевременно сообщаться. Каждый раз, когда разработка завершена, тест может быть проверен напрямую, с акцентом на эффективность. Мок-данные одинаково отвечают за тестирование, и один и тот же набор данных используется для разработки и тестирования, чтобы уменьшить недопонимание. Окончание периода отмечается «обзорной встречей» через две недели, на которой тест разработки демонстрирует завершенный бизнес-сценарий продукта.
1 неделя рефакторинга:Эта неделя соответствует «ретроспективной встрече» в гибкой разработке, а также неделе для полного общения между продуктами, тестированием и разработкой. Продукт тестируется в компании в течение недели, проводится приемка, собирается обратная связь, предоставляется информационная поддержка для следующего дизайна продукта. С одной стороны, ошибки в разработке могут быть исправлены, а главное, по содержанию «ретроспективной встречи» процесс может быть улучшен, а «технический долг» может быть своевременно реконструирован. Разработка компонентов также может выполняться для улучшения повторного использования кода в будущем.

специальный

Имитация данных

Предыдущие данные Mock были ответственностью самих разработчиков, либо путем непосредственного написания кода, либо с использованием таких инструментов, как Charles. Теперь Mock-данные единообразно отвечают за тест и генерируются непосредственно на уровне BFF.
В прошлом разработчики должны были писать код самотестирования и код модульного тестирования; после данных вариантов использования при разработке тестов обычно требовалось разработать самотестирование с помощью инструментов процесса, таких как JIRA. Текущий режим заключается в тестировании постоянного обслуживания фиктивных данных в BFF и преобразовании разработанного варианта использования вФактические доступные фиктивные данные, Используйте один и тот же набор стандартов для разработки и тестирования, чтобы сократить технологические и коммуникационные потери.

внутренняя версия

Внутренняя версия, завершенная разработкой и тестированием «большого внешнего интерфейса», представляет собой полуфабрикат, которому не хватает фактической внутренней поддержки. После внутреннего выпуска попробуйте запустить его на внутреннем тестовом сервере. (Версия разработки работает на сервере разработки). Данные, необходимые для запуска, имитируются тестом.
Эта внутренняя версия не может использоваться реальными пользователями, но внутренние продукты, разработка, тестирование могут использоваться для получения опыта, поиска ошибок и т. д.
Также это очень удобно для back-end разработки, после того как сервис разработан, есть готовые продукты для тестирования, что может избавить от многих хлопот.
Так же очень удобно отчитываться перед начальством или показывать клиентам.На самом деле есть доступные продукты для опробования, хотя данные муляж. Это полностью отличается от просмотра документов Word, ppts, прототипов или диаграмм пользовательского интерфейса.
Стоимость модификации небольшая, вообще говоря, 70% работы разрабатывается в фоновом режиме, а 30% работы приходится на «большой фронтенд». В течение недели внутреннего тестирования обнаруженные проблемы или изменения требований могут быть легко завершены в следующей итерации версии. В настоящее время разработка фоновой службы еще не началась или только началась, и стоимость изменений очень мала.

инфляция спроса

В прошлом, если вы хотели разработать функцию, в первую очередь обращали внимание на то, на что похожа внутренняя логика. Во многих случаях необходимо модифицировать отображение страницы, порядок взаимодействия и т.д. согласно существующей логике бэкенда. представляет собой «внутреннюю модель, основанную на функциях».
Теперь продукт вместе с «большим интерфейсом» как минимум на одну итерацию опережает серверную часть. Когда вы сталкиваетесь с моментом сильного изменения спроса или моментом, когда возникают большие дебаты, вы можете подумать о том, чтобы внутренняя версия работала немного дольше, например, на две или три версии вперед. После того, как продукт станет прозрачным и в основном стабильным, будет добавлена серверная часть. Таким образом, фокус продуктового мышления смещается с существующих функций серверной части на фактические потребности клиентов. «Модель разработки по требованию» освобождает мышление о продуктах и упрощает разработку продуктов, которые соответствуют ожиданиям клиентов.
Первоначальная модель состоит в том, что задняя часть толкает переднюю часть, но текущая модель состоит в том, что продукт и передняя часть тянут заднюю часть, и способ мышления совершенно другой.
«Модель разработки большого внешнего интерфейса, ориентированная на спрос»: сначала есть доступный продукт, выясните, что нравится пользователям, а затем подключитесь к внутренней реализации.
«Модель разработки, основанная на внутренних функциях»: сначала проведите анализ потребностей, оцените существующие внутренние функции, а затем найдите способы удовлетворить потребности клиентов.
Возникает вопрос: «Знает ли клиент или пользователь, чего он хочет? Может ли анализ потребностей быть эффективным?». Условно говоря, если есть что-то реально используемое, пользователям легче понять, чего они хотят. Например, «этот цвет лучше изменить», «кнопка здесь некрасивая, лучше ее убрать», «Хочу видеть здесь больше информации, лучше ее добавить». и так далее

плавный ритм

Функциональная организация и каскадная модель развития выгодны для контроля рисков, недостатком является то, что время слишком велико, как правило, проект длится не менее 1 месяца, а способность противостоять изменениям спроса слаба. Это плановая модель.
Гибкая модель разработки способствует командному общению, и время обычно короткое, обычно от 2 до 4 недель. Что касается риска, то здесь меньше внимания уделяется, как правило, он используется в первую очередь, и, если будут обнаружены проблемы, он будет изменен в следующем цикле. Это эмпирическая модель.
Сочетание этих двух факторов позволяет достичь баланса риска и скорости, формируяплавный ритм. Цель увеличения количества совещаний по планированию и ретроспективе, которые изначально длились 4 часа в гибкой модели, до недели, состоит в том, чтобы сделать межведомственное общение более полным, сделать принятие продукта более всесторонним и снизить риски.
Сосредоточьте ресурсы на «важных, но несрочных вещах». Потребности клиентов очень важны, но от идеи до реализации это не так быстро. Таким образом, гибкие преимущества «большого фронтенда» могут быть использованы для того, чтобы клиенты могли увидеть реализацию идей раньше, что может превзойти ожидания клиентов.
«Изменение спроса» само по себе также является потенциальным потребительским спросом. Часто клиенты не знают, чего хотят, пока не воспользуются доступным продуктом. Таким образом, принятие двухэтапного метода доставки и использование полуфабрикатов с «большими предварительными этапами» с общей стоимостью разработки около 30% для удовлетворения потенциальных потребностей клиентов может повысить удовлетворенность клиентов.
«Имеющиеся продукты лучше, чем полные документы», хотя это полуфабрикат, с точки зрения клиентов, он более реалистичен и надежен, чем текстовые документы, дизайн прототипа и т. д.

Сосредоточьтесь на рефакторинге

А как насчет технического долга? Должен ли он обрабатываться сразу или он должен обрабатываться централизованно после того, как накопление достигнет определенного уровня?
Бросить бизнес и специализироваться на рефакторинге Можно сказать, что такая возможность встречается, но не востребована.
Продление ретроспективной встречи не более чем на 4 часа в оригинальном agile на фазу рефакторинга на 1 неделю как раз для решения проблемы накопления технического долга. Для достижения эффекта «замена двигателей во время полета».
На этом этапе продукт и бизнес не остановились на испытаниях, на опыте, на проверке того, соответствует ли концепция дизайна в начале реальности. Это приводит к беспроигрышной ситуации для продукта и технологии.

Обратите внимание на предварительные исследования

Здесь первоначальная 4-часовая «планерка» в гибкой разработке была продлена до 1 недели.
При внедрении гибкой модели предполагается, что требования определены, дизайн прототипа, ресурсы пользовательского интерфейса, внешний и внутренний дизайн интерфейса и другие ресурсы готовы, а также соответствующая осуществимость, то есть предварительное исследование было завершено, а затем откройте "план" встречи"
Реальность такова, что условия, упомянутые выше, часто не подготовлены или отсутствуют. В середине разработки часто обнаруживается, что логика взаимодействия не приземляется, и прототип нужно менять. Или выясняется, что ресурсов пользовательского интерфейса не хватает, определение интерфейса нецелесообразно и так далее.
Такая потеря информации более вероятна, особенно в функциональных организациях, которые взаимодействуют между отделами.
Перед официальной разработкой очень важно потратить неделю, чтобы сосредоточиться на общении, провести предварительное техническое исследование, провести полную подготовку и найти проблемы до начала проекта, что очень важно для сокращения ненужных переделок.

Программирование для BFF

BFF становится абстрактным интерфейсом между «большим интерфейсом» и серверной частью.
BFF должен сделать обе стороны адаптации
Подумайте о том, чтобы взять на себя некоторые государственные услуги, чтобы достичь цели «легкого клиента».
Естественно «горячее обновление», BFF использует внутреннюю технологию и выполняет работу «большого внешнего интерфейса». Если есть модификация, обновите сервис, она вступит в силу, и естественно горячее обновление.
Естественно "кроссплатформенный", BFF модифицируется в одном месте, и может работать со всех сторон.
Повысить контроль. BFF обслуживается предприятиями, а различные терминалы находятся в руках пользователей. Перемещение бизнеса с разных сторон в BFF может значительно улучшить контроль над предприятием. Граница здесь такова: «Если это можно реализовать на стороне сервера (BFF), не размещайте его на стороне клиента, если только вы не столкнетесь с серьезными проблемами производительности».
Обратите внимание на узкое место производительности, которое является ключевым узлом и точкой соединения между передней и задней частями. А также обратите внимание, что после подключения Mock-данные должны быть очищены, чтобы гарантировать, что данные рабочей версии исходят из реального бэкэнда.

Эффективность и безопасность одновременно

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

считать

«Большой передний конец» — это недавняя концепция. По сравнению с традиционным интерфейсом, «большой интерфейс» имеет два расширения. Одним из них является разнообразие терминалов, таких как добавление iOS, Android, мини-программ, официальных аккаунтов и так далее. Другой — расшириться до серверной части, например, рост Node.js, возможно, написание серверных сервисов не так зрело, как Java, а написание BFF все еще компетентно.
«Большой интерфейс» относится к традиционному интерфейсу, iOS, Android, H5 и другим независимым небольшим командам. Из двух аспектов основных услуг + бизнес-поддержки, чтобы способствовать интеграции команды. Улучшите повторное использование и эффективность в нескольких аспектах, таких как архитектура, цепочка инструментов и компонентизация.
"Большой интерфейс" постепенно предлагается с тенденцией к разделению фронт-энда и бэк-энда. Он связан с бэк-эндом. Поэтому необходимо достичь цели быть независимым от бэк-энда. конец, уменьшая зависимость, и сотрудничая друг с другом и общаясь ясно.
Понятие "большой фронтенд" изначально было распространено с Али, а затем самым известным стал Ele.me. Сейчас его используют многие компании. Вместе с микросервисами растет и принятие, и это стало тенденцией. .
Когда «большой интерфейс» реализуется конкретно, фиксированной модели не существует, и планы каждой компании не одинаковы. Есть успешные примеры для справки, но нет зрелых моделей для тиражирования. Вам нужно исследовать и двигаться вперед в соответствии со своей конкретной ситуацией.

Справочная статья

Создание BFF с GraphQL под микросервисы
Разделение и эволюция внешнего и внутреннего интерфейса: если вы не можете использовать микросервисы, используйте BFF для изоляции.
Схема эволюции серверной архитектуры мобильных приложений для стартапов
Практика лучших друзей Ant Fortune
Понимание архитектуры BFF
Большая конференция по передовым технологиям
Когда мы говорим о большом переднем конце, о чем мы говорим?
Как собрать и управлять «большой фронтенд-командой»: расшифровка большой фронтенд-команды Ele.me
"Big Front End"/"Big Wireless", как я понимаю
Технический директор Mangeek Ли Ян: Путь к большому внешнему интерфейсу - Как объединить трехэтапную (веб-, десктопную, мобильную) разработку с веб-технологиями