Я буду тренировать в миланском выпуске Всемирного дня кодекса в субботу; всемирное мероприятие, проводимое в 100 городах, будет посвящено 45-минутным итерациям разработки симулятора игры жизни.
Само событие сконцентрировано не на Игре Жизни, а на решении этой проблемы с помощью нескольких методов (внешнее или основанное на единицах TDD, карты CRC, возвраты не принимаются). Тем не менее, я углубился в проблему и решил ее, потому что для меня было честным увидеть все, что было до того, как я попытался тренировать других людей.
Однако обратите внимание, что я сформировал свое понимание работы коуча как человека, который может помочь в подходе к проблеме и постановке правильных вопросов, а не в предоставлении ответов. Даже если я знаю , решение, я никогда не должен предлагать куски его разработчикам быть тренировали: идти с китайской пословицей, тренер должен научить дать вам рыбу, но учит вас , как рыба.
Эта проблема
Игра Жизни состоит из бесконечной сетки квадратных ячеек, каждый в живом или мертвом состоянии. Происходит моделирование с дискретным временем, в котором каждое поколение является функцией предыдущего:
- мертвая клетка становится живой, если живы ровно 3 ее соседа.
- Живая клетка умирает, если живы менее 2 ее соседей (изоляция) или более 3 (переполнены).
Учитывая начальную конфигурацию, игра развивается без дальнейшего вмешательства. Симуляция интересна тем, что игра не хаотична, и даже с этими простыми правилами существует много стабильных конфигураций, которые остаются фиксированными, вращаются, циклически перемещаются или даже перемещаются по сетке.
Решая это
Игра представляет собой неплохую самодостаточную проблему, и я потратил всего 4 часа на создание полного симулятора, включая визуализацию из командной строки:
X X X XX
с некоторыми перерывами на обед и голосование.
В моем конкретном случае я выбрал смешанный подход, который начинался с классов Поколения, а не с Игровой (снаружи) или Сотовой (снизу вверх). У меня уже было несколько идей о том, как формировать код из моего предыдущего опыта в прошлом году.
Разработка, управляемая тестами, конечно же, является основной техникой, которую нужно усовершенствовать, решая проблемы с катами такого типа.
Вот некоторые случайные вещи, о которых я должен был заботиться:
- Примитивная одержимость : обход переменных x и y не очень хорошо масштабируется.
- Названия концептов: легко запутаться в ячейке и позиции, поэтому, если вы используете эту концепцию, дайте точное определение, включать ли состояние, чтобы избежать недопонимания.
- Представление : структура данных, в которой перечислены все ячейки, не может представлять бесконечную сетку. Более того, некоторые структуры данных могут помочь при рассуждении по ячейкам: например, наборы и списки.
- Функциональный подход : вы можете решить проблему с неизменяемыми структурами данных и составом операций над ними (например, объединение и пересечение множеств). Тем не менее, вы можете разработать тот же подход с Value Objects на языке OO (в моем случае PHP), следуя большей части той же логики.
Проблема визуализации
Печатать бесконечную сетку непросто, и при выборе ее части вы должны сделать некоторые предположения, которые потребуются владельцу продукта. ? Чем более эзотерически хранятся ячейки, чтобы их бесконечное число помещалось в вашем конечном ОЗУ, тем сложнее будет работа по переводу этой структуры данных обратно в визуальный вывод.
Если вы решаете эту проблему, я предлагаю не заниматься визуализацией, если у вас нет готовой библиотеки или времени, достаточного для ее разработки после механизма моделирования. Разработчикам очень приятно видеть, что их код работает немедленно, и экспериментировать с семенами активных ячеек, но это может занять дополнительные 50% времени по сравнению с простым решением в памяти.
Более того, TDD устраняет необходимость во многих ручных тестах и оставляет только ознакомительные сценарии в качестве точки, где вам потребуется визуализация.
Выводы
Я постараюсь не быть довольным своим собственным решением, когда люди начнут разрабатывать свои собственные, разные и одинаково действительные. Существует множество различных реализаций Game of Life, и нет правильного ответа на ката, где нет выраженных нефункциональных требований (хотите ли вы простой в обслуживании код? Или высокую производительность и масштабируемость?)
Я обычно с открытым исходным кодом все, что я пишу для упражнений, но я не буду публиковать свое решение до GDCR. ?