Регламент Ariol · Frontend разработчик

Регламент работы Frontend-разработчика

Стандарт клиентской разработки Ariol: интерфейсы, состояния, доступность, производительность, интеграция с API и стабильность пользовательских сценариев.

Цель регламента

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

Зона ответственности

UI-компоненты, страницы, состояния, маршрутизация, формы, интеграция с API, адаптивность, доступность, производительность и сборка.
Frontend отвечает за пользовательский сценарий целиком: loading, empty, error, success, validation и edge cases.

Обязанности специалиста

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

Рабочий порядок

Разобрать задачу: сценарий пользователя, макеты, API, права, состояния, ограничения устройств.
Согласовать спорные состояния: пустой список, ошибка, загрузка, длинный текст, медленная сеть.
Реализовать интерфейс на существующих компонентах и стилевых правилах проекта.
Проверить адаптивность, интерактивность, формы, фокус, ошибки и интеграцию с API.
Собрать production build и устранить визуальные/консольные ошибки.
Передать QA список проверенных сценариев и известных ограничений.

Обязательные артефакты

Компонент или страница в коде.
Список состояний интерфейса.
Скриншоты desktop/mobile при необходимости.
Описание API-зависимостей.
UI acceptance checklist.
Краткие release notes для пользовательских изменений.

Критерии качества

Интерфейс не считается готовым без проверки mobile, desktop, длинного контента и ошибок API.
Нельзя оставлять кликабельные элементы без понятного состояния hover/focus/disabled/loading.
Нельзя ломать существующие компоненты ради частной страницы без согласования изменения паттерна.

Метрики контроля

Core Web VitalsОшибки JSBundle sizeВремя загрузки сценарияДефекты UI после релизаДоступность ключевых сценариев

Коммуникации и эскалация

Неясности в макете или API фиксируются до реализации, а не маскируются временными решениями.
Frontend заранее сообщает backend и QA о контрактных изменениях и новых состояниях.
Перед релизом разработчик передает QA короткий список затронутых экранов и сценариев.