nanamyyu / discraft Goto Github PK

• Упаковать Python-часть кода (Discord-бот) в Docker-контейнер (Т.к. способ упаковки Java-части кода (Minecraft-плагин) жёстко определён Minecraft'ом.)

• Class Algorithm - слишком общее название. Предлагаю Authorizer или что-то вроде того
• Подклассы для зарегистрированного и обычного юзера делать НЕ надо, лучше заюзать паттерн State (инкапсулировать логику работы каждого состояния и переходов между ними в класс(ы))

• Пока что в диаграмме классов маловато подробностей. Выглядит так, что для каждой из ответственностей класса из CRC-карточек были придуманы имена методов и исходя из этого нарисована диаграмма классов. Нужно добавить больше подробностей. (Хотя, конечно, у вас скорее не сложная статическая структура у системы, а сложное поведение - так что наличие хорошей диаграммы последовательности/стейт-машины/диаграммы активности очень поможет.)
• Подумалось, что класс User должен где-то хранить информацию о привязанных аккаунтах юзеров в дискорде. Подумайте, насколько важны в вашей объектно-ориентированной модели классы для доступа к БД пользователей? Это out of scope для подробной UML-модели или нет?
• Discord_bot: у метода get_id не очень удачное название. Лично я не очень понимаю, чем он отличается от generate_id и какую функцию выполняет? Предлагаю пояснить его функциональность (комментарием здесь) + поменять имя метода на более подробное. Не бойтесь подробных имён, они помогают тому кто читает модельки и код 😊
• Пока не очень понимаю, как классы с диаграммы взаимодействуют в happy path сценарии "известный нам пользователь дискорда хочет зайти на майнкрафт-сервер, где есть наш плагин". Мне сначала показалось, что вся история начинается с Authorizer, а потом - что с User. И по диаграмме классов мне непонятно, кто из (User, Authorizer, Console) - фасад с удобным интерфейсом, реализующий сложную функциональность с помощью используемых им низкоуровневых классов, а кто - собственно эти более низкоуровневые используемые классы.
• Вместо слова "использует" можно заюзать стандартный синтаксис UML для передачи такого отношения: <<uses>>. (Если у вас есть между классами ещё интересные отношения кастомные, их можно передать, нарисовав ассоциацию и подписав её <<ваше кастомное отношение...>>).
• Нужна диаграмма, которая описывает динамическую составляющую вашей системы: как её компоненты друг с другом взаимодействуют, чтобы достичь желаемой цели (выполнить юзер-стори 😊). Это может быть диаграмма последовательности/стейт-машина/диаграмма активности — в зависимости от того, больше у вас последовательной логики/перехода между состояниями/какого-то гибрида из этого 😊

• Максимально сфокусироваться в Vision на основной идее проекта (офигенной!) — Single Sign On
• Популярность Discord среди геймеров — основная причина успеха, остальное, кажется, вторично. Так и стоит написать в разделе про Успешный Успех™
• Риски: если в команде раньше не писали на Java, обозначьте этот риск в Vision. Эффект Даннинга-Крюгера никто не отменял: пока нет опыта разработки на новом языке, всегда кажется что понимаешь и умеешь больше, чем на самом деле :-(
• [бюрократическая мелочь] Product Vision и User Stories лучше написать отдельными .md-файлами в репозитории, а не в README.md. Или заюзать Wiki :-)

Замечания по User Stories я оформлю отдельным Issue, когда пользовательские истории появятся в репозитории :-)

Замечания по третьему релизу, обязательные к устранению:

• Явно прописать открытие портов для Discord-бота в команде docker run (-p ...:...), явно выбрать режим сети (например, использовать хостовую сеть: --net=host). А ещё лучше - использовать для подъёма контейнера с ботом docker compose: там можно в уютном YAML-файлике прописать и настройки файловой системы (вольюмы), и настройки портов и сети, и переменные окружения, и многое другое.
• Задать для Docker-образа тег (обычно тег=номер версии). Бывает ещё тег latest, но это конвенция, он не строго обязателен.

Требования к четвёртому, последнему релизу:

• Настроить в CI-системе GitHub Actions компиляцию проекта и запуск тестов на каждый коммит в ветке main и в пул-реквестах, вливаемых в ветку main.

[опционально] Бонусы к четвёртому, последнему релизу:

• +0.05: Настроить сборку проекта из ветки main в исполняемый артефакт (в вашем случае - Docker-образ), триггер сборки - push в ветку main. Собранный вами Docker-образ должен загружаться в репозиторий контейнеров, например, в DockerHub (но можно и в приватный репозиторий контейнеров в любом из популярных облачных провайдеров).

• Первая и вторая истории очень похожи, отличаются только мотивацией пользователя (Discord-аккаунта не жалко/Discord-аккаунт - единственный, который у него есть). Я бы объединил их в одну
• Ни в первой, ни во второй истории не указано, как пользователь поступает при повторных запросах авторизации? Код, который ему отправляют в Discord - одноразовый (на каждую авторизацию мы отправляем ему новый код), что безопаснее, или многоразовый, и его надо пользователю как-то у себя хранить?
• В третьей истории я бы уточнил, и писал не "Пользователь..." а "Владелец или администратор Minecraft-сервера..."
• Про владельца/админа сервера я бы ещё подумал и, возможно, добавил историй. Скорее всего, админ/модератор захочет банить людей вошедших через Discord-аккаунт (будет ли это отличаться от обычного бана? подумайте), и смотреть кто заходил через Discord и получилось ли у них (лог аутентификации) чтобы детектировать атаки и т.д. А ещё такое банальное - кто-то захочет выключить ваш плагин (временно) или удалить его (навсегда), это тоже пользовательская история, кажется (как минимум, если ваш плагин где-то будет хранить персистентное состояние, при удалении он точно должен его стереть, при выключении - не знаю.)

• Реализовать сценарий "админки": администратор сервера хочет посмотреть статистику (сколько сейчас юзеров залогинено, сколько кто находится в на сервере) или забанить некоторых пользователей :-D
• Добавить валидацию и обработку исключительных ситуаций (если их ещё не было)
• Написать юнит-тесты и обеспечить покрытие Statement или Line >= 70%. Классы, представляющие собой "обвязку" (например, принимающие и обрабатывающие пользовательский ввод, конфигурирующие используемые фреймворки и т.п.) - тестировать НЕ надо