Что мы строим?

Проект

Платформа для проверки домашних заданий курса

Инструмент, которым будут пользоваться следующие потоки студентов

Вы сами пользовались им в прошлом семестре и можете поделиться болями и идеями о том, как их решить

У студента есть личный кабинет с оценками и списком домашних заданий.
У каждого задания отслеживается дедлайн.
Студент сдаёт ДЗ через Pull Request

Ментор смотрит diff, оставляет inline-комментарии, меняет статус

Под капотом

GitHub Classroom

Мы не изобретаем хранилище кода и инфраструктуру для автоматического тестирования

Мы делаем удобный интерфейс поверх GitHub API

Мы не просто пишем код для учебного задания

Это настоящая продуктовая работа в команде

У нас есть продукт, который нужно доставить пользователям

У нас есть тикеты, борды и дизайн-система

У нас есть процессы - груминг, декомпозиция, стендап, ретро

У нас есть заказчик

Вопросы

Что не нравилось в ДЗ прошлого семестра?

Какие трудности были при выполнении ДЗ?

Что бы вам помогло понять как и когда проверит ментор?

Как вы работали с замечаниями ментора?
Особенно с теми что вновь и вновь переоткрывались

Чего ещё не хватило?

Формат хакатонов

• Три хакатона по 5-8 часов в субботу
• Каждый хакатон - это спринт
• Утром договариваемся что делаем
• Днём делаем
• Вечером показываем результат и проводим ретро

Между хакатонами

Работа не останавливается

Задачи продолжаются

Менторы доступны в чате для вопросов и ревью

Роли

Кто есть кто

Как строится работа?

Процессы команды

Тикеты и доска

Вся работа живёт в GitHub Issues

Каждая задача - отдельный issue. Внутри - чеклист подзадач.

Статусы двигаете сами по ходу работы

Тикеты и доска

Тикеты и доска

Статусы задач

Приоритеты

Ветки и PR

Каждый issue - отдельная ветка

Ветку линкуете к issue - тогда issue закроется автоматически при мёрже

Стратегия веток

Все ветки вливаются в develop

main - только для релизов

В main напрямую никто не пушит (не только лишь все)

Conventional Commits

Code Review

Без апрува ментора в develop не мёржится

Дизайн-система

В продуктовой команде есть единый набор UI-компонентов

Не изобретаем кнопки и инпуты - берём из библиотеки

shadcn/ui

Компоненты копируются в проект - полный контроль над кодом

Легко кастомизировать через Tailwind CSS

Стильно, модно, молодежно

Документация

Дизайн-макет

У нас в команде нет дизайнера, поэтому дизайн отдается на откуп программистов и их менторов.

Но, есть примерный референс - какие страницы с какой информацией скорее всего понядобятся.

План на сегодня

Расписание

*Чистого времени на код - около 4 часов

Issue 1

Инициализация проекта

Priority: 0   Size: M  

Issue 1 - описание

Поднять Next.js с App Router и подключить весь стек

Результат - приложение запускается локально и npm run build проходит

Этот issue разблокирует всё что связано с вёрсткой и компонентами

Issue 1 - стек

Issue 1 - тикеты

• create-next-app с TypeScript и App Router
• PostCSS: postcss-preset-env + sass
• ДС: @shadcn
• Zustand: установить, создать skeleton store
• Path aliases: @/ -> src/

Issue 1 - кто ответственный?

Issue 2

Качество кода - ESLint, Prettier

Priority: 1   Size: S

Issue 2 - описание

Настроить ESLint и Prettier так чтобы весь код выглядел одинаково

Вне зависимости от того кто его писал

Это не бюрократия - это то что делает code review предметным

Ментор смотрит на логику, а не на стиль

Issue 2 - тикеты

• ESLint: Next.js + TypeScript + import-order
• Prettier + eslint-config-prettier
• Скрипты в package.json: lint, lint:fix

Issue 2 - кто ответственный?

Issue 3

CI/CD и деплой

Priority: 1   Size: M

Issue 3 - описание

Настроить GitHub Actions и Vercel

Каждый PR автоматически проверяется и деплоится на preview-URL

Issue 3 - тикеты

• GitHub Action: job lint на каждый PR
• GitHub Action: job build на каждый PR
• Подключить Vercel
• Preview deployment на каждый PR
• Автодеплой main в production
• Статус CI блокирует мёрж при падении

Issue 3 - кто ответственный?

Issue 4

Архитектура и соглашения

Priority: 0   Size: S

Issue 4 - описание

Договориться о структуре проекта и зафиксировать её в коде и документации

Без этого у каждого будет своё представление о том куда что класть

Через неделю репозиторий превратится в хаос

Feature-Sliced Design

src/
├── app/          # Next.js App Router: layouts, pages, providers
├── features/     # Фичи: auth, homework, pr-viewer, admin
├── entities/     # Сущности: user, homework, pr, review
├── shared/       # UI-кит, утилиты, конфиг API, типы
└── widgets/      # Составные блоки страниц

Обсуждение

Какие страницы нам нужны в сервисе?

Разделить их на 4 группы:

• Общие страницы
• Страницы для студентов
• Страницы для менторов
• Страницы для администраторов

Issue 4 - тикеты

• Написать README.md: стек, структура, команды запуска, нейминг коммитов и PR
• Создать FSD-структуру папок в репозитории
• Добавить правило в ESLint для сохранения FSD
• Создать стори для каждой группы страниц и декомпозировать их по страницам группы

Issue 4 - кто ответственный?

Issue 5

Авторизация через GitHub OAuth

Priority: 0   Size: L

Issue 5 - описание

Весь вход в платформу - через GitHub. Никаких логинов и паролей

После авторизации запрашиваем роль с бэкенда

Роль хранится в JWT-сессии, используется в middleware и компонентах

Стек: Auth.js v5 (NextAuth) + GitHub provider

Issue 5 - тикеты

• GitHub OAuth App в настройках Organization
• Auth.js с GitHub авторизацией
• После логина - получение роли с бэкенда
• Роль хранится в JWT-сессии
• Страница `/login` с кнопкой «Войти через GitHub»
• Редирект на профиль после логина

Issue 5 - кто ответственный?

Issue 6

Роутинг, layout и API-моки

Priority: 1   Size: L

Issue 6 - описание

Скелет приложения: все основные страницы существуют

Роли защищают маршруты, контент различается по роли пользователя

Фронт работает полностью без бэкенда через NEXT_PUBLIC_USE_MOCKS=true

Issue 6 - тикеты

• Маршруты - выбор и реализация
• Middleware: неавторизованные -> /login
• /admin закрыт для всех кроме admin
• Layout: Header (аватар, имя, роль, logout) + Sidebar + main
• Заглушки для роутов
• TypeScript-интерфейсы в shared/api/types.ts
• Мок-данные в shared/api/mocks/
• Zustand store: текущий пользователь + роль

Issue 6 - кто ответственный?