serggitxab / p_aa_s7_1_act Goto Github PK

• Summary
• Stack
• MVP
• Backlog
• Структура проекта
  • Бэкенд
  • Фронтенд
• Работа на проекте
  • С чего начинать
  • О таскборде
  • Как выполнять задачи
  • Проверка задач
  • Требования к коду
  • Созвоны по проекту

Реализуем функционал авиакомпании на основе прототипа - S7 Airlines.

Проект рассчитан на студентов, успешно завершивших этап Pre-Project в Kata Academy.

Проект пишется на базе Java 11, Spring Boot 2, Maven и архитектуре REST. Работаем с базой данных MySQL через Hibernate.

Чтобы не писать boilerplate-код, используем на проекте Lombok.

Все контроллеры и их методы нужно сразу описывать аннотациями Swagger. Swagger UI при запущенном приложении крутится здесь.

Таск-борд находится прямо на Gitlab.

Dev-stand будем поднимать и разворачивать через Docker, а настраивать CI/CD - через Gitlab.

MVP - API (полностью описанное в Swagger), которое будет уметь продавать, менять, возвращать авиабилеты. Работать с таким API можно будет через веб-интерфейс Swagger и Postman.

Фичи:

• диверсификация перевозок (багаж, животные, oversized-вещи, грузы)
• создание личного кабинета пассажира, добавление аутентификации через логин/пароль, Google, социальные сети
• реализация функционала обратной связи с пассажиром через e-mail и Telegram
• создание личного кабинета администратора
• внедрение бонусной системы (мили), кэшбека и акций
• внедрение проверок пассажиров по стоп-листам - общение с микросервисом "МВД"
• добавление смежных сервисов - подбора гостиниц, аренды квартир, тренферов, каршеринга, экскурсий. Все - микросервисы.

Импрувменты:

• логирование через Slf4j + log4j2
• юнит-тесты и интеграционные тесты
• анализ качества кода через SonarQube

Проект основан на архетипе webapp. Слои:

• config конфигурационные классы, в т.ч. Spring Security, инструменты аутентификации
• entities сущности базы данных
• repositories dao-слой приложения, реализуем в виде интерфейсов Spring Data, имплементирующих JpaRepository.
• services бизнес-логика приложения, реализуем в виде интерфейсов и имплементирующих их классов.
• controllers обычные и rest-контроллеры приложения.
• util пакет для утилитных классов: валидаторов, шаблонов, хэндлеров.

Вьюшки будем писать на html и js (AJAX/FetchJS). Красоту наводить - с помощью Bootstrap или (если будет настроение) - Material UI.

0. Доступы. Если ты читаешь это, значит доступ к проекту у тебя уже есть :)

1. загрузи проект себе в среду разработки
2. изучи весь проект - начни с pom, properties файлов и конфигурационных классов
3. создай локальную базу данных с названием airline_db
4. добейся успешного запуска проекта. Проверить.
5. изучи таск-борд

Таск-борд строится по принципу Kanban - он разделён на столбцы, каждый из которых соответствует определённому этапу работы с задачей:

• Backlog / Future задачи на новый функционал, выполнение которых отложено на более отдалённый срок
• Postponed НЕ БРАТЬ. Это задачи, которые будут перенесены в TODO позже. Они технически и/или хронологически зависят от выполнения каких-то задач, которые сейчас в TODO.
• TODO задачи, требующие выполнения
• In Progress выполняемые в данный момент задачи
• Cross-review задачи на этапе перекрёстной проверки студентами
• Final Review задачи на проверке у техлида
• In Reworking задачи, направленные на доработку
• Closed выполненные задачи

• в графе TODO на таск-борде выбери карточку с задачей и назначь её себе для исполнения
• загрузи себе последнюю версию ветки dev
• создай от dev свою собственную ветку для выполнения взятой задачи. Свою ветку назови так, чтобы было понятно, чему посвящена задача. В начале имени ветки проставь номер задачи с Gitlab. Например, 313_adding_new_html_pages
• выполни задачу, оттестируй и, если всё ок, залей её в репозиторий проекта
• создай на своей ветке merge request, в теле реквеста укажи Closes #здесь-номер-таски". Например, Closes #313
• перенеси задачу в столбец Cross-review

На этапе кросс-ревью студенты проверяют задачи, выполненные друг другом. В случае, если к коду есть замечания, проверяющий как можно более подробно описывает их в комментарии к карточке задачи и переносит её в столбец In Reworking. Если к коду претензий нет, проверяющий студент ставит к карточке лайк.

Каждая карточка (студенческая задача) должна быть проверена как минимум 2 другими студентами и одобрена ими (т.е. собрать не менее 2 лайков).

Только после этого карточку можно переносить в столбец Final Review.

Затем код проверяет техлид (ментор) и в случае обнаружения ошибок переносит её в столбец In Reworking. Если всё ок - merge request принимается, ветка студента сливается с основной веткой проекта, а карточка переносится в столбец Closed.

• сделайте себе понятные никнеймы (имя + фамилия) в Git. Не хочу гадать, кто, где и что писал.
• для каждого класса и его содержимого пишите комментарии в формате Javadoc:
  • над классом: что это за класс, зачем нужен. Описывайте поля.
  • над методом: что делает, какие параметры принимает (и что это такое), что возвращает.
• свободно создавайте собственные вспомогательные классы в пакете Util - типа утилиток для страховки от null и типа того.
• в REST-контроллерах пользоваться аннотациями Swagger - причём как сами контроллеры в целом, так и их отдельные методы.
• на полях сущностей можно и нужно расставлять констрейнты для проверки формата, длины введённых значений, проверки чисел на положительность и т.д.
• пишите Commit message как можно более подробно! Желательно на анлгийском, но если никак - можно и на русском.

Если в процессе разработки вы пришли к пониманию того, что требуется создать какую-то ещё сущность - создавайте карточку и вперёд)

1. В каждый метод необходимо добавить логирование с описанием произведенной операции на уровне info.

2. Если объект не найден, вывести сообщение уровня warning ("not found" или "does not exist") с описанием произведенной операции.

Созвоны проходят по вторникам и четвергам оговорённое время. Регламент:

• длительность до 15 минут
• формат: доклады по 3 пунктам:
  • что сделано с прошлого созвона
  • какие были/есть трудности
  • что будешь делать до следующего созвона
• техлид (ментор) на созвонах код не ревьюит

Любые другие рабочие созвоны команда проводит без ограничений, т.е. в любое время без участия техлида. Договаривайтесь сами :)