Привет. По просьбе нашего техдира я начал описывать процесс разработки фронта. Документ будет полезен как внутри компании, так и снаружи. На данный момент я набросал простенькую структуру. Мне интересно мнение опытных людей, взгляд со стороны.
1. Сбор требований к проекту (что входит в ближайший релиз и в следующий) 2. Макетирование (дизайнеры собирают карту взаимодействий) 3. Нарезка на библиотеку компонентов (на карте взаимодействий) 4. Определение зависимостей компонентов для всех экранов 5. Выделение паттернов дизайна (общая разметка, повторяющиеся блоки, тянущаяся верстка, адаптивная верстка) 6. Первая реализация библиотеки компонентов (карта состояний в storybook, поверхностное unit-тестирование) 7. Определение необходимых данных для каждого экрана 8. Определение требований к бекенду (методы API) 9. Первичная сборка 1-3 разных экранов по внешнему виду 10. Составление диаграммы процессов приложения (1-3 сценария по выбранным экранам) 11. Имплементация выбранных сценариев предметной области (на языке программирования) 12. Прототипирование экранов с привязкой к сценариям (моки API, graybox реализация без глубокой обработки ошибок) 13. Ретроспектива прототипа (анализ сценариев, анализ прототипов, анализ ошибок, анализ библиотеки компонентов и паттернов) 14. Составление карты сущностей и отношений 15. Составление карты ролей, политик и разрешений (RBAC / ABAC / ACL / ...) 16. Отображение карты взаимодействий на карту роутов (доступ, параметры, переходы) 17. Последовательная имплементация основных сущностей, роутов и прав доступа (тестирование) 18. Параллельная имплементация сценариев, сгруппированных по области ответственности (тестирование) 19. Ретроспектива релиза (список неудачных решений, список полностью решенных задач, список узких мест производительности и архитектуры, список удачных архитектурных решений, что можно улучшить перед реализацией следующего релиза)
А релиз это что в данном контексте? При CI как это работает? По дизайну вопрос. Есть допустим протипы (еще без красивого ui), там кнопка одна серая квадратная, на реальном дизайне оказывается что кнопок 5. А блок не влез в реальном дизайне из-за тенюшек и скруглений, а надо поменять прототип. Если карта взаимодействий – это UX step, то прежде чем выделять некие паттерны нужно увидеть финальный UI, хотя девелопер ревью для процесса дизайна не помешает. На выходе у дизайнеров уже обычно готовы киты компонентов, т.к. дизайнеры работают по такому же принципу. Страница кнопок, страница типографики, страница иконок и т.п., которые потом реюзаются по проекту. Далее также еще до целых страниц обычно есть страница с вариантами и состояниями основной карточки, меню и проч. Сразу подкорректировать названия для консистентности и можно пилить ui основу на этом. Макеты дизайнеры собирают из своих компонентов, аналогично фронтам, где ui kit = ui repo совпадают максимально.
Я бы посмотрела на хороший пример карты сущностей, ролей и т.п. Полезная штука, редко кто рисует.
>8. Определение требований к бекенду (методы API) Тут вопрос смотря какой продукт. Может бекенд свои требования спустит, т.к. три независимые базы для секьюрности и они используются для других сервисов к тому же. А может federated graphql. Но в идеальном мире наверно да, со стороны фронта сразу проектировать данные, но при скейле это может все полететь.
Хороший документ, не совсем ясно какой тип проектов может по нему работать?
Я бы посмотрела на хороший пример карты сущностей, ролей и т.п. Полезная штука, редко кто рисует.
>8. Определение требований к бекенду (методы API)
Тут вопрос смотря какой продукт. Может бекенд свои требования спустит, т.к. три независимые базы для секьюрности и они используются для других сервисов к тому же. А может federated graphql. Но в идеальном мире наверно да, со стороны фронта сразу проектировать данные, но при скейле это может все полететь.
Хороший документ, не совсем ясно какой тип проектов может по нему работать?