yutsareva / game-of-life Goto Github PK

• Багфиксы и тесты
  • Пофиксить баг с установкой iters_count=-1 из командной строки.
    Интересно: если поменять в конфигурационном файле, то почему-то работает
  • Больше тестов и тестового покрытия богу юнит-тестов! (долг со второго релиза, см. #4)
• Фичи
  • Выгрузка результатов симуляции в файл (долг со второго релиза, см. #4)
  • Добавление фигур (команда add_figure)
  • Цветной вывод живых и мертвых клеток (ANSI escape-коды терминала)
  • Изменение правил работы автомата (тоже CLI-командой?)
• Инфраструктура
  • Сборка с помощью jlink, GraalVM native-image или Docker

@yutsareva @GSKolesnikov @Avonazhrets @safiullinzufar

Случайно увидел, что в вашем проекте оказывается есть документ по ОО-дизайну:
https://github.com/yutsareva/game-of-life/blob/main/project-structure.md

Уведомлений об этом мне не приходило :-(
В следующий раз, пожалуйста, когда всё готово - призывайте меня в комменты (@nvamelichev), заведите Issue или Pull Request. На эти события у меня настроены уведомления, а просто на коммиты в репозитории - нет (слишком шумные были бы уведомления).

В целом, дизайн неплохой, для первой итерации - в особенности 👍 👍 👍

Замечания по той версии ОО-дизайна, что я увидел:

• Высокоуровневой дизайн системы в документе перемешан с подробным описанием классов. Пожалуйста, разделите их:
  • Общее описание системы - сделайте в отдельным документом;
  • Описание всех подклассов и их поведения, алгоритма работы Runner - сделайте отдельным документом (если описание будет текстом) или несколькими диаграммами (если описание будет [UML-]диаграммами).
• Класс Cell:
  • Для высокоуровневого проектирования: класс можно оставить "как есть", потому что концептуально сущность "Клетка" в системе есть.
  • Для уточнённого проектирования: кажется, класс Cell не очень нужен. Судя по текущему набору публичных методов, это просто обёртка над логическим значением (boolean): жива клетка или мертва. Класс Cell можно вовсе убрать, а внутри класса Field эффективно представить строки (или столбцы) игрового поля как BitSet'ы (естественно, в публичных методах BitSet не отдавая). В таком случае, ответственность по получению состояния клетки и её изменении перейдёт в класс Field: getCell(), setCell().
• Интерфейс Rules ("правила"), стоит переименовать в Automaton ("автомат") или, точнее, CellularAutomaton ("клеточный автомат"). Название "Rules" подразумевает, что правила - основное, что есть в публичном интерфейсе класса, это то, чем он занимается. Но судя по публичному интерфейсу класса Rules - он трансформирует игровое поле и проверяет, можно ли ещё выполнить трансформацию. То есть, для пользователя он выглядит не как "набор правил", а как "клеточный автомат", работающий над прямоугольным игровым полем.
• Интерфейс Reader:
  • Кажется, интерфейс описан слишком подробно. Лучше просто сказать, что у вас в системе есть класс, который умеет прочитать состояние игрового поля и правила откуда-то. Какие конкретно у него будут методы - не очень интересно, это уже детали реализации, отвлекающие от самого интересного - клеточного автомата, игрового поля и т.д.
  • Возможно, недостаёт интерфейса Writer. Подумайте, возможно, логично выглядит функциональность сохранения состояния, чтобы пользователь мог продолжить "с середины", опционально немного изменив настройки? Это, кстати, выглядит как новая вполне валидная User Story для юзера который хочет позалипать над красивыми картинками. Если решите добавить такую функциональность, обновите и ОО-дизайн, и требования к проекту (user-stories.md) :-)
• Очень хочу увидеть более подробное описание поведения системы, чем цикл while в описании класса Runner. Вполне можно (и даже желательно) не кодом, а UML-диаграммой (Sequence / State Machine / Activity).

• Сборка одним из следующих способов: Docker-образ, GraalVM native-image, jlink)
• Настроена система непрерывной интеграции, запускающая тесты через Maven/Gradle на каждый коммит в main и на каждый коммит в пул-реквестах. CI берите любую бесплатную и интегрирующуюся с GitHub'ом: GitHub Actions, Travis CI, …
• Все члены команды хорошо знакомы с фичами продукта и могут их продемонстрировать Product Owner'у (т.е. мне :-))

• Перенести Vision и User Stories в отдельные файлики vision.md, user-stories.md
• Vision:
  • прописать риски проекта
  • перенести идеи про "задавать правила / начальную конфигурацию / существующие фигуры" в User Stories, это уже уточнение того, что "[Пользователь]... расставляет или генерирует начальную конфигурацию «живых» клеток..."
• Подумать и записать в Vision свои соображения, каких пользователей больше - пассивных наблюдателей (которые хотят посмотреть красивую картинку/рандомную картинку), исследователей игры "Жизнь", ...?
• Исходя из предположений о пользователях, скорректировать и расширить User Stories (см. предыдущий пункт)

• Юнит-тесты теперь обязательны (если ещё не сделаны — сделайте!)
• Починить баг с загрузкой конфигурации поля из файла
• В конце симуляции предлагать выбор: продолжить симуляцию на столько же шагов/запустить симуляцию с начала/закончить симуляцию
• Медитативный режим (бесконечное количество шагов, прерывание по Ctrl+C)
• Выгрузка результатов симуляции в файл