yutsareva / game-of-life

Game of life

Build

$ mvn clean install
$ java -jar target/game-of-life-1.0.jar run

Commands

$ java -jar target/game-of-life-1.0.jar help

Examples

Run with green alive and yellow dead cells:

$ java -jar target/game-of-life-1.0.jar run --color_alive green --color_dead yellow --iters_count 100

Infinite run:

$ java -jar target/game-of-life-1.0.jar run --iters_count -1

Run with figures:

$ java -jar target/game-of-life-1.0.jar reset
$ java -jar target/game-of-life-1.0.jar set_params --size 20 20
$ java -jar target/game-of-life-1.0.jar add_figure --type pulsar --place 2 2
$ java -jar target/game-of-life-1.0.jar add_figure --type pulsar --place 3 3
$ java -jar target/game-of-life-1.0.jar run --iters_count 10

Run from docker

$ docker pull dockertsareva/game-of-life:latest
$ docker run dockertsareva/game-of-life:latest run --color_alive blue --color_dead red --iters_count -1

game-of-life's Issues

Комментарии по ОО-дизайну

@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).

Замечания по документации с семинара

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

Второй релиз до 23.04

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

Третий релиз

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

Четвёртый релиз до 21.05

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