Playbook
Процессы

Code Review

Процесс проверки кода перед merge.

Процесс проверки кода перед merge.

Чек-лист для Reviewer

1. Готовые решения (standard-ready-made-solutions)

  • Использованы shared-модули (если применимо)
  • Использованы Nuxt UI компоненты
  • Кастомный компонент обоснован (если есть)

2. Структура и именование (standard-project-structure, standard-component-naming)

  • Файлы в правильных директориях
  • Компоненты именованы с префиксом модуля (OrderFilters, не Filters)
  • Нет конфликтов имён компонентов

3. Декомпозиция (standard-component-decomposition)

  • Компонент ≤ 200 строк (или обоснование)
  • Одна ответственность на компонент
  • Сложная логика вынесена в composables
  • Tailwind классы ≤ 7-10 на элемент

4. Auto-imports (standard-auto-imports)

  • Нет импортов Vue (ref, computed, watch, etc.)
  • Нет импортов компонентов
  • Нет импортов stores/composables
  • Пути типов используют ~/types/

5. Composables (standard-composables)

  • Бизнес-логика в composables (не в компонентах)
  • Именование use[Domain][Action]
  • Возвращает reactive объект

6. TypeScript (standard-typescript)

  • Нет any (используй unknown или generic)
  • API ответы типизированы
  • Нет избыточной типизации (типы выводятся автоматически)

7. Формы (standard-forms-validation)

  • UForm + Zod для валидации
  • Маски для телефонов/БИН
  • Loading состояние на submit

8. Адаптивность (standard-responsive-design)

  • Mobile-First подход (без префикса = mobile)
  • Нет фиксированных размеров (используй max-width)
  • Touch-targets минимум 44x44px (padding, не margin)
  • Таблицы имеют мобильную версию или скролл

9. UX Quality (standard-ux-quality)

  • Работает в светлой и тёмной теме
  • Кнопки имеют loading состояние
  • Списки показывают Skeleton при загрузке
  • Пустые состояния имеют кнопку действия
  • Ошибки предлагают решение (повторить, сбросить)

10. Backend API (standard-service-layer, standard-error-handling)

  • Хэндлер тонкий — только валидация, вызов сервиса, ответ
  • Бизнес-логика в сервисном слое, не в хэндлере
  • Ошибки через AppError с кодом и статусом
  • Zod-схемы в shared/schemas/ (используются и на клиенте, и на сервере)
  • Prisma-запросы не в хэндлерах (через сервис или repository)

11. Безопасность

  • Нет SQL injection — используется Prisma (параметризованные запросы), raw-запросы через $queryRaw с template literals
  • Нет XSS — не используется v-html с пользовательским вводом, данные экранируются
  • Авторизация проверена — пользователь имеет доступ к запрашиваемому ресурсу (IDOR)
  • Секреты не попадают в код — API ключи, токены только через runtimeConfig / env vars
  • Rate limiting на чувствительных эндпоинтах (auth, upload)
  • Валидация входных данных на сервере (не только на клиенте)

12. Code Quality

  • Код читаемый
  • Нет console.log
  • Нет закомментированного кода

Формат комментариев

Блокирующий

🔴 [BLOCK] Нарушение стандарта:
Удали импорт `ref` — auto-import в Nuxt.
См. [[standard-auto-imports]]

Важный

🟡 [IMPORTANT] Вынеси логику в composable.
См. [[standard-composables]]

Suggestion

💡 [SUGGESTION] Можно упростить:
const isActive = computed(() => status.value === 'active')

Процесс

  1. Author создаёт MR
  2. Автоматические проверки (lint, typecheck)
  3. Reviewer проверяет по чек-листу
  4. Author исправляет комментарии
  5. Approval и merge

Связанные документы

Backend Development

Workflow разработки backend-функционала на Nuxt Server.

Frontend Development

Workflow разработки фронтенд-функционала.