Как написать интерфейсную проектную документацию

Что такое интерфейсный проектный документ?

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

  • Реализуемость потребностей(Может ли это быть сделано в теории, может ли это поддерживать определенную функцию, может ли быть реализовано определенное взаимодействие и не слишком ли велика стоимость реализации функции), предполагая, что вы можете достичь любой функции, которую вы погладите по груди. и сказать в ПМ, то Та упомянултакая потребность...
  • Общая архитектура требований(Процесс и метод взаимодействия с интерфейсом и сервером, путь интерфейса, параметры запроса и ответа)
  • конкретный дизайн потребностей(Дизайн front-end страниц/компонентов/сервисов)

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

Зачем писать интерфейсную проектную документацию?

Measure twiceandcut onceПодумать дважды

• Если функция всех продуктов состоит в том, чтобы отображать на странице Hello, World, то нам, вероятно, не нужны проектные документы, но реальные требования к продуктам полны сложности, и страница может отображать данные из множества разных источников. Детали и тщательные бизнес-процессы требуют, чтобы мы подумали о том, можно ли реализовать эту функцию и как ее реализовать, прежде чем начинать разработку.

• Только представьте, какие Плохие Окончания могут случиться, если вы не напишете проектную документацию, засучите рукава и начнете работать?

  • Случай 1. Требование требует подключения к стороннему SDK. Вы провели небольшое совещание со сторонними студентами, занимающимися исследованиями и разработками, и обнаружили, что проблем не возникло. Вы не выполнили подробный технический проект, чтобы проверить, может ли SDK полностью поддерживает требования, и вы его не тестировали.SDK, получается, что функции SDK не могут полностью поддерживать ваши бизнес-потребности в середине разработки.Если вы хотите его поддерживать, вы должны иметь стороннюю поддержку планирования , а этот проект изначально рассчитывали на скорейший запуск, ты тупой (Первая кровь🙅)
  • Случай 2: функция в требовании требует, чтобы вы запрашивали несколько интерфейсов одновременно.Вы не полностью учли аварийное восстановление сбоя этих интерфейсов, и возврат этих запросов зависит от судьбы.В результате пользователи часто сталкиваются запрос интерфейса, который успешно используется после выхода в сеть.Еще один не удалось, что приводит к противоречивым данным, функция обратной связи с пользователем недоступна, вы снова глупы (Double Kill! 🙅)
  • Кейс 3: Есть необходимость разработать всплывающее окно в заявке.Вы беглый взгляд и думаете что его можно разработать за полдня.В итоге вы не до конца учли что это всплывающее окно имеет пять режимов, три формы и восемь процессов, и недооценил 2/3 рядов.Точка, когда график истекает, почему QA не призывает вас к тестированию, и после спешного завершения теста появляется куча багов, ты еще раз глуп (Triple Kill! 🙅)

Я три глупых Старка?

• Дизайн предварительных документов заключается в том, чтобы определить технически неопределенные моменты как можно раньше до разработки и заранее продумать метод проектирования требований, чтобы уменьшить вероятность рисков и проблем в последующей разработке.Хотя технические документы не могут быть предсказуемым на 100% Или оценить все потенциальные риски и проблемы, но техническая документация может значительно снизить такие риски.

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

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

Как написать хороший документ по дизайну интерфейса?

• Поскольку написание проектной документации может лучше помочь нам создать сокровища и избежать расстановки приоритетов в начале разработки, то написание проектной документации должно быть очень необходимой вещью.Согласно этому мнению, наша новая проблема заключается в следующем: как написать хорошую проектную документацию?
• Автор считает, что квалифицированный конструкторский документ должен соответствовать как минимум нескольким условиям.
  • Полный контент
    • Проектный документ отражает использование вашего мозга для завершения моделирования процесса требования. Он должен содержать все связи, состояния и среды, связанные с требованием. Вам необходимо учитывать ваши отношения с вышестоящими и нижестоящими и то, как вы запрашиваете услуги. Или как другие люди используют ваш сервис, в какой среде работает ваша страница (браузер/веб-просмотр/CEF) и влияние этих связанных ссылок, если есть проблема с вами, если есть ситуация, которой вы пренебрегаете, это может быть все онлайн-проблема или несчастный случай;
    • При разработке своих страниц и функций вы должны четко перечислить все функции этой страницы или компонента, а также какие изменения состояния и взаимодействия имеют эти страницы или компоненты. Только когда эти аспекты будут полностью учтены, возможна более объективная оценка. много работы.
    • Кроме того, в дизайн-документе должны быть собраны всевозможные документы и материалы, необходимые для разработки, чтобы повысить оперативность поиска необходимой информации, например, в шаблоне документа, разработанном фронтендом авторской команды, будет собран следующий контент
      • Требования к документу
      • Макеты дизайна
      • IDL сервера
      • Документация сторонних сервисов/SDK
      • прецедент
      • Погребенный документ
      • Список операционных ресурсов (необязательно)
      • Прохождение и прием документов
  • Четкая структура: разумная и четкая организация документа может отражать порядок вашего мышления, а также его легко понять другим.Автор обычно использует общие требования-страница-компонент/модуль для организации плана дизайна, точно так же, как вы разрабатываете a React/Vue Для страницы или компонента сначала спроектируйте родительский компонент, а затем подумайте о функциях составляющих его подкомпонентов (базовые модули и службы также могут быть разработаны в первую очередь в соответствии с конкретной ситуацией), просто как повар, если вы можете понять общую структуру и каждый компонент.Если структура и границы между ними четко определены, я считаю, что модульность вашего кода будет лучше.
  • Простота реализации: идеальный проектный документ должен позволять другим видеть ваш документ и знать, как реализовать требования (этот стандарт действительно идеален), но если проектный документ написан, вы все равно не знаете, как его разработать. или Если есть сомнения, то этот проектный документ может быть несовершенным. Лучший проектный документ должен быть похож на руководство Lego или IKEA. После прочтения документа вы должны знать, как с ним работать.
• Это некоторые теоретические описания проектной документации, остановимся на некоторых более конкретных деталях.
  • Если вы разрабатываете новое приложение
    • Создайте новый репозиторий Git
    • Инициализация проекта
    • Процесс развертывания проекта
    • Мониторинг доступа
  • Если вы разрабатываете новую страницу
    • Маршрут страницы и соответствующий запрос
    • Общая функция и структура дизайна страницы
  • Если вы собираетесь разрабатывать компонент, вам нужно подумать о:
    • Страница на самом деле имеет много общего с дизайном компонентов, все они состоят из трех компонентов.
      • Состояние: какое состояние есть, локальное состояние или состояние, которое нужно получить через интерфейс?
      • Пользовательский интерфейс: пользовательский интерфейс, из каких частей состояние диска меняется в пользовательском интерфейсе?
      • Логика: что это за логика?Эти логики можно разделить на несколько типов подлогик (манипулирование данными, реагирование на события, вызов служб), как эти логики изменяют состояние и как они реагируют на взаимодействие с пользователем или другие события?

Возьмем пример 🌰

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

• Во-первых, прочитав документ с требованиями, мы понимаем, что это требование примерно состоит из двух частей.
  • (1) Требования к C-стороне: добавьте вход во всплывающее окно обслуживания клиентов на странице в пользовательском клиенте/приложении.
  • (2) Требования к стороне B: в фоновом режиме обслуживания клиентов, когда студенты обслуживания клиентов выбирают сеанс пользователя, они могут видеть информацию о пользователе/информацию о курсе/информацию о заказе.
• Давайте запустим весь мозг, чтобы запустить этот процесс от С-терминала к В-терминалу.
  • Пользователи оставляют отзывы на стороне C
  • C-сторона обслуживания клиентовSDKОпределите идентификационную информацию пользователя и передайте предоставленную информацию обратной связи в базу данных службы поддержки клиентов.
  • Служба поддержки клиентов на стороне B может просматривать отзывы после входа в систему и получать идентификационную информацию пользователя.
  • Служба поддержки клиентов B-end может продолжать просматривать информацию о пользователе, информацию о заказе (учащиеся) или информацию о курсе (учитель) после выбора этого сеанса обратной связи.
  • Наконец, блок-схему можно резюмировать как

• Учитывая общую структуру процесса, давайте подумаем о деталях ключевых звеньев.
  • обслуживание клиентовSDKКак идентифицировать идентификационную информацию C-конечных пользователей?
  • Различия в суждениях об идентичности конечных пользователей C, когда они входят в систему и когда они не входят в систему?
  • Как сторона B получает идентификационную информацию ответчика
  • Как реализовать страницу с информацией о пользователе/информацией о курсе/информации о заказе на стороне B? Это инженерная разработка на платформе обслуживания клиентов или с использованием iframe?
  • Если это iframe, как указанные выше три страницы получают идентификационную информацию ответчика?
  • После обсуждения и проектирования платформы обслуживания клиентов дизайн может определить
• После того, как технический процесс и план определены, мы должны приступить к конкретному проекту реализации функции.
  • С-концевая часть:
    • Поскольку стиль и функция всплывающей кнопки на каждой странице одинаковы, нам нужно разработать компонент всплывающей кнопки.
    • Нижний уровень компонента всплывающей кнопки вызывает SDK обслуживания клиентов, поэтому нижний уровень должен разработать модуль всплывающих окон обслуживания клиентов.
    • Введите компонент всплывающей кнопки на странице, которая должна ввести всплывающую запись службы поддержки клиентов.
  • В концевая часть
    • Поскольку мы решили внедрить набор страниц iframe в платформу обслуживания клиентов, нам нужно запустить независимый склад отдельно, и нам нужно выполнить некоторую работу по настройке.
    • Разработайте три страницы iframe: информация о пользователе / ​​информация о курсе / информация о заказе
    • Когда эти компоненты ясны, мы можем приступить к разработке конкретных деталей.
• Когда мы добираемся сюда, можно сказать, что общий процесс требований, методов взаимодействия с интерфейсом и сервером и реализации конкретных функций в основном завершен.Когда мы начинаем строительство в это время, техническая неопределенность уменьшается. , а идеи развития тоже ясны в груди.Можно сказать, литературные мысли как пружины, а ключи как боги⌨️
• Конечно, даже этот шаг нельзя назвать концом размышлений, в разработке, совместной отладке, тестировании и развертывании еще могут быть неожиданные вещи, но с постепенным улучшением ваших проектных идей и практик такие случайности могут происходить. Относительно снижено, даже если это произойдет, вы можете сделать это с легкостью, всегда обеспечивать качественное и оперативное выполнение заказа и стать надежным партнером команды👏

Наконец, прикрепите шаблон дизайн-документа интерфейса авторской команды.

1. Предыстория требований и ресурсы

• фон спроса
• Сопутствующая документация и ресурсы
  • Документ с требованиями:
  • Макет дизайна:
  • ИДЛ сервера:
  • Документация сторонних сервисов/SDK
  • Прецедент:
  • Похороненный документ:
  • Список операционных ресурсов (необязательно):
  • Проходные и приемочные документы:

2. Расписание

• Хронология спроса

	рассмотрение	дизайн	развивать	Совместная отладка	тестовое задание	онлайн
Дата

• Разделение расписания

	График (чел/день)	Владелец модуля
Модуль 1
Модуль 2
Всего человеко-дней

3. Расчетная схема

• Общая программа

  • Строительство проекта
  • План развертывания
  • Решение для мониторинга

• дизайн страницы

  • описание страницы
  • URL
  • Пользовательский интерфейс и логика взаимодействия (разделение пользовательского интерфейса)
  • условие
  • логика запроса
  • Бизнес-логика
  • Погребенная логика

• дизайн компонентов

  • Описание модуля
  • Пользовательский интерфейс и логика взаимодействия
  • Статус / Реквизит
  • Бизнес-логика
  • Погребенная логика

• общий модуль

  • Описание модуля
  • Бизнес-логика

4.Todos

• Дизайн
• развивать
  • Страница 1
  • Компонент 1
  • Универсальный модуль 1
• Совместная отладка
• тестовое задание
• Пошаговое руководство по пользовательскому интерфейсу
• онлайн

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