Если я руководитель фронтенд-команды, как сделать хороший сводный дизайн?

внешний интерфейс Управление командой
Если я руководитель фронтенд-команды, как сделать хороший сводный дизайн?

ЕСЛИ я руководитель группы фронтенда, как разработать совместную спецификацию фронтенда?Количество Nuggets превысило 740👍, спасибо за вашу поддержку, эта статья является продолжением предыдущей. Продолжайте знакомить вас с моими мыслями и исследованиями в области управления фронтенд-командой.

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

Согласно определению из учебника, проектирование программного обеспечения — этоэто процесс преобразования требований в программные операторы (выражения). обычно естьЭскизный проект (или эскизный проект, Эскизный проект)а такжеДетальный дизайнПлановый дизайн преобразует требования в данные и программные структуры, а детальный дизайн уточняет структуру в определенные структуры данных и программные алгоритмические выражения. Эта статья посвящена эскизному дизайну внешнего интерфейса.

По сравнению с back-end разработкой, для front-end «дизайн программного обеспечения» упоминается редко, и может случиться так, что работа front-end всегда была относительно «простой», поэтому она относительно обширна. Как правило, документы прототипа и интерфейса предоставляются, и работа начинается непосредственно. Но по мере того, как работа интерфейсного разработчика становится все более сложной или размер проекта/команды увеличивается, нам все чаще требуется тщательное проектирование перед кодированием.

так какЛидер по началу работы с интерфейсом, Недавно я столкнулся с некоторыми проблемами: такими как проблема разделения труда в проекте и отсутствие документации по сопровождению проекта, что заставило меня обратить внимание на стадию проектирования программного обеспечения.С текущей точки зрения, сделайте хорошую работу в передней частиСводный дизайн, по крайней мере, со следующими преимуществами:

  • заранееКонструкторский документ является планом разработки, и последующая разработка может осуществляться поэтапно по этому документу. Хороший дизайн держит развитие в нужном русле.
    • На этапе проектирования мы дополнительно разберем бизнес-процесс, углубим понимание бизнес-процесса и даже выясним неразумные вещи в бизнес-процессе.
    • Разделение модулей. На этом этапе мы определим границы и перекрытия между различными модулями и извлечем перекрывающиеся (общие) части. Кроме того, модуль является основной рабочей единицей разработки, а также основой для разделения труда и оценки времени в нашей команде.
    • Изучите ключевые технические моменты. Предлагайте различные варианты, полностью учитывайте различные риски и выбирайте тот, который соответствует реальным потребностям.
  • после, Проектная документация очень помогает при сопровождении программного обеспечения и добавлении функций после проведения мероприятия.

Начнем с введения, передняя часть находится вэтап проектирования программного обеспеченияЧто-то следует учитывать, или фронт-энд概要设计文档Что в нее должно быть включено.Конечно, это только некоторые предварительные идеи.После дальнейшей практики эта статья будет продолжать обновляться и повторяться.


Схема статьи


серия статей


В этом плане у меня меньше опыта и практики, и я никогда не оставался на большом заводе, поэтому эта статья лишь некоторые мои мысли и попытки, которые могут быть нереалистичными. Если у вас или вашей команды есть лучшие практики в этой области, поделитесь ими со мной. Спасибо 🙏



Разобраться с ключевыми бизнес-процессами

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

Так было много раз в реальных проектах:Когда проект достигает стадии тестирования, тестировщик обнаруживает, что бизнес-реализация приложения отличается от определения продукта или что бизнес-процесс нецелесообразен.. На самом деле это ошибка очень низкого уровня, цена изменений может быть очень высокой, и это может даже сделать всю вашу работу напрасной.

У компаний с более зрелым управлением будет много способов избежать подобных ошибок.

Например, для определения четких документов требований, в связи с этим, вы можете имитировать методы написания некоторых стандартов/спецификаций (Spec), строго определять некоторые ключевые слова и избегать двусмысленных описаний;

Кроме того, можно использовать различные встречи по рекламе и внедрению, чтобы собрать вместе соответствующий персонал и представить требования унифицированным образом. Эти встречи можно использовать для мозгового штурма, уточнения или уточнения определения требований, выявления дефектов и рисков, анализа осуществимости и многого другого. Благодаря постоянному общению участники могут обмениваться сквозными знаниями и обеспечивать последовательное понимание бизнеса.


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

Например, например, мы делаем функцию «скан-код входа». Мы можем разобраться с кросс-терминальным бизнесом:


Из приведенного выше бизнес-прочесывания мы можем определить основное поведение и статус бизнес-объектов.Например, диаграмма перехода состояний QR-кода:


Конечно, бессмысленно просто добавлять, удалять, проверять и изменять длину объяснения.Мы фокусируемся только на важных для приложения бизнес-процессах.

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



ключевые технические моменты

Описать ключевые технологии/алгоритмы, используемые приложением, или считатьсяТехнический отбор.

Например, есть типичные приложения для живого видео, и задействованы различные решения для прямой трансляции:

  • RTMP-протокол
  • RTP-протокол
  • HLS-протокол
  • flv.js
  • WebRTC-протокол
  • так далее

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

Если имеется несколько альтернатив, в конце следует выбрать рекомендуемую и объяснить причины и соображения, связанные с выбором.

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

О том, как сделать технический отбор, я вЕСЛИ я руководитель группы фронтенда, как разработать совместную спецификацию фронтенда?Для краткого обсуждения вы можете обратиться к нему.



конструкция модуля

Современные интерфейсы обычно используюткомпонентное мышлениеразвивать,На данный момент наше приложение фактически представляет собой дерево компонентов, состоящее из компонентов с разной степенью детализации., это дерево компонентов в конечном итоге будет отражено в структуре каталогов проекта.На этапе проектирования мы можем идентифицировать различные страницы и компоненты на основе прототипов продуктов или эскизов дизайна пользовательского интерфейса..

Для обычных приложений мы можем разделить его на три уровня:

начальный уровень

Немного более сложное приложение может иметь несколько порталов, и страницы, отображаемые этими порталами, могут сильно различаться.Вот общее разделение:

  • Разделенные по подсистемам: такие как передний план и фон.
  • Разделены по ролям: например, администратор, обычные пользователи
  • Разделено по записи: например, мобильные, настольные и т. д.

слой страницы

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

Что касается разделения модулей, я рекомендую использоватькарта разумаБудьте организованы.Разделение модуля Эта ссылка, вы можете позвонить другим членам команды, чтобы открыть встречу вместе с мозгом. Мы ссылаемся на прототип, распознаем границы и пересечение различных модулей или компонентов, предназначенные для обсуждения того, как текучесть данных страницы, интерфейсы компонентов и т. Д., Таким образом, коллективный разум может быть использован для более разумного разделения модулей, а также может помочь членам команды заранее ознакомиться со структурой проекта.

такРазработка программного обеспечения не является делом только архитекторов или дизайнеров. Всех следует поощрять к совместному участию. Проектные документы являются результатом работы всей группы разработчиков программного обеспечения и накоплением знаний команды..

После того, как вышеприведенное приложение разделено по слоям страниц, результат будет примерно следующим:

На этом этапе мы определим следующее:

  • Дизайн страницы и маршрутизации определяет иерархические отношения между страницами.
  • Процесс взаимодействия и передача данных между страницами

Что касается дизайна маршрутизации, вы можете следовать некоторым спецификациям, которые рекомендует автор.Спецификация URL-адреса Restful, этостатьяТоже хорошо написано.

Передача данных между маршрутами обычно осуществляется следующими способами:

  • Небольшой объем данных: может передавать переменные маршрутизации (например,/posts/:id) или в виде строки запроса. Также, если вы используетеВнешний режим маршрутизации на основе History API, вы можете использовать историюstateобъект для хранения некоторого состояния (максимум 640 КБ)
  • Большой объем данных: можно хранить через глобальные переменные, или механизм менеджера состояний, как бы это ни хранилось в памяти, оно будет потеряно при обновлении страницы. Таким образом, вы также можете рассмотреть возможность хранения в локальном кеше, таком как LocalStorage.

компонентный слой

Ладно, разделяй дальше, но делай, что можешь. Для очень сложного проекта, в котором могут быть тысячи или сотни компонентов, и эти компоненты могут постоянно меняться в будущем, рассмотрение этих разбиений на этапе проектирования может занять много времени, а преимущества не очевидны.

Итак, как вам нужно понять гранулярность? На самом деле, основная цель этапа проектирования слоя компонентов состоит в том, чтобыНайдите повторяющиеся или структурно похожие компоненты, извлеките их в единый дизайн и повторно используйте на нескольких страницах.Не все компоненты перечислены..

я здесьКраткий обзор практики проектирования компонентов React 02 — организация компонентовВ этой статье я специально расскажу, как компоненты React организованы и разделены. Среди них предлагаются следующие централизованные режимы:

  • Компонент контейнера и компонент представления разделены. Либо раздельное представление и логику, бизнес-компоненты и компоненты дурака.Чистые логические вещи помещаются в хуки, которыми будет удобнее пользоваться.
  • Чистые компоненты и нечистые компоненты Можно считать, что чистые компоненты полностью зависят от внешнего ввода.
  • Компоненты с состоянием и без состояния
  • Компоненты макета и компоненты содержимого
  • Унифицированный дизайн интерфейса однотипного компонента, например, компонент формы должен сохранять единообразие интерфейса

Тем не менее, в приведенном выше примере приложения страница объявления имеет много элементов формы, и они часто меняются.Кроме того, вы обнаружите, что структура страницы приложения аналогична структуре страницы предварительного просмотра, и может страница позади него.

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

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



разделение труда

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

С помощью вышеуказанных шагов мы определили различные модули, а затем нам нужно определить зависимости между этими модулями, которые влияют на то, должны ли они быть реализованы в целом. Наконец, решите их на основе бизнес-приоритетов или зависимостей.кластер модулейприоритет реализации.

Хорошо, теперь эти кластеры модулей можно отсортировать по приоритету плюс время оценки (человеко-день) и организовать в список. Если вы используете Канбан для управления проектами, вы можете опубликовать их как блок задач на Канбан-доске.

1. Foo 功能
  - c 2d
  - d 1d
  - f 3d
2. Bar 功能
  - e 1d
  - h 0.5d
3. Baz 功能
  - g 1d
4. Fu 功能
  - a 4d
  - b 1d

总计人天: 13.5

Существует множество стратегий разделения задач, например:

  • Горизонтальное деление
    • Общие компоненты и бизнес-компоненты (стыковочный бизнес)
    • Сверху вниз и снизу вверх (ссылаясь на дерево компонентов)
  • Вертикальное разделение: согласно независимому вертикальному модульному разделению труда



государственный дизайн

Front-end компонентизация сопровождается различными数据驱动или数据流驱动Модель развития. В этом режиме внешний вид применения такого уравнения можно резюмировать следующим образом:

view = f(state)

то естьПредставление — это карта данных или потоков данных., Важность видимого управления состоянием для современной фронтенд-разработки.

Дизайн состояния аналогичен дизайну внутренней объектной модели.Вам необходимо абстрагировать различные объектные модели в соответствии с требованиями бизнеса и рендеринга страниц, а также уточнить взаимосвязь между объектными моделями.. Этот этап, возможно, нужно будет тесно интегрировано с бэккой, чтобы определить разумную структуру объекта.

Конечно, даже с вашим выбранным проектированием государственного состояния государственной программы управления также имеет отношения, разные состояния идей, воплощенные в схемах управления, совсем разные:Если вы выбираете Redux, состояние приложения представляет собой дерево объектов; если вы выбираете Mobx, состояние приложения может состоять из нескольких объектов модели, что ближе к традиционному шаблону ООП..

Если вы примете метод проектирования ООП, вы можете нарисоватьUMLДиаграмма, которая визуализирует структуру и отношения объектов представления:

(Источник изображения:Цзун Жэнь Что/2016/12/30/…)


я здесьКраткий обзор практики проектирования компонентов React 05 — Управление состояниемВ этой статье много места посвящено представлению идей и способов разработки различных менеджеров состояний, поэтому я не буду их здесь останавливаться:

Дизайн состояния Redux:

Дизайн состояния Mobx:



дизайн интерфейса

Если фронтенд-команда лидирует в дизайне интерфейса или используетАрхитектура BFF (бэкенд, обслуживающий интерфейс), на этапе проектирования нам необходимо спроектировать различные интерфейсы.

Однако доминирование, как правило, находится в руках серверной части.Поскольку клиентская часть меньше заботится о бизнесе, серверная часть обычно учитывает требования к интерфейсу каждой стороны, эффективность хранения базы данных, ремонтопригодность и другие аспекты проектирования. В настоящее время интерфейс является пользователем интерфейса, и мы несем ответственность за проверку соответствия внутреннего интерфейса требованиям.

я здесьЕсли я руководитель клиентской группы, как мне сформулировать спецификации для совместной работы?О различных спецификациях интерфейса уже упоминалось, здесь они повторяться не будут.



Планирование версий

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

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

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


В планы на этот релиз входит следующее:

  • номер версии
  • время выпуска
  • Включены основные модули


проверять

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

Продукт или тестовый запуск могут рассматривать приложения только с бизнес-уровня, нам нужна перспектива исследований и разработок, учитывать всененормальная ситуация,узкое место производительности,провестиоценка рисковОжидаются варианты ответа для уточнения рисков.

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


Требования и цели проекта

Некоторые требования необходимо определить заранее, для фронтенда более типичны требования совместимости с браузером. Не ждите, пока проект появится в сети, прежде чем указывать требования пользователя для совместимости с IE6!

Эти программные требования могут повлиять на нашу оценку затрат на разработку, выбор, тестирование и другие факторы. По сути, для фронтенд-проекта эти требования должны быть заданы заранее:

  • Совместимость с браузером
  • Операционная среда, такая как операционная система, апплет и т. д.
  • момент времени
  • Требования к индексу производительности. Например, индекс первого экрана, индекс объема данных


указатель документов

Разработка внешнего интерфейса проекта может быть связана со многими документами. Эти документы разрознены. Лучше всего объединить их в проектные документы для быстрого доступа и ссылок. Например:

  • Документ с требованиями
  • DEMO, проект пользовательского интерфейса
  • прецедент
  • документация по интерфейсу
  • Документ спецификации дизайна пользовательского интерфейса
  • Внешний документ спецификации
  • ...


инструкции по сборке

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

НапримерКак скомпилировать и запустить? Как тестировать и отлаживать? Как развернуть или опубликовать?Как устроен код?рабочий процесс разработки,соглашения о кодированиитак далее

С помощью этих инструкций новые участники могут быстро приступить к разработке.


Итерировать непрерывно

Дизайн-документ не разовый, он должен следовать непрерывной итерации проекта, иначе смысл документа будет потерян.



шаблон

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

# XXX 概要设计文档

## 背景

填写项目的背景, 或者开发或重构的目的/出发点.

## 关键业务流程

可以放置关键的业务流程图、状态图、对象图等等. 梳理关键的业务流程

## 关键技术描述

可选, 描述项目中使用到的关键技术、算法、选型结论等等

## 模块拆分

- 入口
- 页面路由
- 组件设计

可以使用思维导图描述

## 状态设计

描述应用涉及的关键领域对象, 比如外形、行为和关系. 如果是OOP方式，可以使用UML描述

## 接口设计

可选，如题

## 项目要求和目标

项目目标、运行环境、兼容性要求、性能指标等等

## 验证

可选, 风险评估、异常情况考虑、特殊测试规则、测试指导等等

## 分工和版本计划

可选, 可以在单独文档或者看板中维护

## 构建说明

可选, 项目组织、构建、测试说明

## 文档索引

相关文档的索引和链接

## 参考资料

文档中索引页的外部参考资料

## CHANGELOG

列出本文档修改的历史纪录。必须指明修改的内容、日期以及修改人

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

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


Суммировать

Статья почти закончена, увидел Жиху@张明云В современной разработке программного обеспечения, как выполнить этап детального проектирования?Один из следующих ответов:



Это в основном соответствует тому, что я описал выше. Проектный документ «схемы» программного обеспечения в основном содержит эти большие части.

Эта статья закончилась.


использованная литература

Категории