Java for fun: Змейка с помощью TDD

Привет. Не так давно в стенах КПИ был проведен наш мастер-класс по Test Driven Development подходу. Из обратной связи стало понятно, что ребятам хотелось бы увидеть процесс TDD разработки от начала и до конца. По этой причине было снято следующее видео. Исходники можно качнуть тут - Snake.rar).

Итак задание:
Реализовать модель змейки (игра на тетрисе). Поле квадратное, любых размеров, змейка длинной в 2 пикселя. На поле со старта появляется 1 камень и 1 яблоко, при съедании яблока змейка удлиняется и тут же появляется еще одно. Если повернуться на 180 градусов, то она умирает. Если съесть себя, камень или стенку - змейка умирает.

Чтобы попробовать змейку был реализован так же консольный контроллер + UI. Текущая картинка поля выводится на консоль (в виде символов), управление клавишами A+Enter - влево, D+Enter - вправо, W+Enter - вверх, S+Enter - вниз. Просто Enter - продвинуться еще на один шаг.

На этом видео можно посмотреть пример "игры".


А вот и видео многочасовой разработки (устраивайся по-уютнее, бери попкорн и айда смотреть :))


Реализация:
В основном по TDD. В некоторых местах были допущены некоторые часто допускаемые ошибки TDD, а в результате использован дебаг - сделано это для того, чтобы показать к чему ведет нарушение базовых правил:
- После каждой итерации красный-зеленый-рефакторинг должен происходить commit в svn.
- Рефакторинг всегда по чуть-чуть, но отдельной итерацией.
- RnD в коде с помощью дебагера.
- Правило "чуть что сразу rollback". Если чувствуешь, что куда-то не туда зашел - rollback. Если поломано больше одного теста - rollback. Если итерация занимает более полу часа - rollback. После rollback'а последних изменений текущую задачу стоит пересмотреть и упростить.

В принципе, все эти правила можно и нужно нарушать, но это не рекомендуется делать на начальном этапе привыкания к TDD.

Вторая часть видео - 

причесывание проекта при свежем взгляде на него через пару дней. Так стоит поступать с любым кодом, который собираешься сдать. нет предела совершенству, но как минимум 1 раз улучить свой проект стоит. В этом заплыве я не брезгую дебагом, и как и в прошлый раз вы можете проследить сколько процесс отладки занимает времени. Тут же использую самописные моки (хотя мог и воспользоваться, к примеру, EasyMock фреймворком - не делал это сознательно, чтобы было понятна суть объектов-имитаторов), Inversion of Control и Dependency Injection. Тут же была добавлена новая функциональность и проведен достаточно непростой рефакторинг - тесты помогли сделать это быстро и без ошибок.

Если удивляет время, затрачиваемое на написание этого проекта (9,5 + 3 часа) , стоит учесть что:
1) написать как можно быстрее - не было целью этой демки.
2) в ходе записи демки я слушал музыку а все пояснения писал текстом в редакторе, чего не делал бы в реальном проекте. В общем кодил с учетом того, что это будут потом смотреть.
3) в целях образования были допущены ошибки, которые привели к последующей отладке.
4) разработка велась в ночное время (с 10 и до 7 утра), потому как в дневное у нас работа :)

В любом случае, задача была бы решена не меньше, чем за один рабочий день (~6 часов) в лучшем случае.

Если у тебя другие идеи на этот счет и ты программируешь на javа. Присылай свою версию игрушки. Сильно на UI не отвлекайся, хочется видеть движок игры. Целью было написание модели игры, а в UI я написал то, что пришло в голову. Так же советую и тебе поступить.

Как засекать время - на твое усмотрение. Меня же интересует больше другие показатели:
1) сколько потребуется времени, чтобы добавить новую фичу не поломав старый код.
2) посмотреть качество (читабельность) кода.
3) как быстро можно улучшить структуру кода (рефакторинг), по замечаниям от читателей, не поломав игру.

Все замечания по видео прошу постить в комменты или почтой.

Спасибо.

P/S/ Исходный код пригодился в будущем нам в проекте codenjoy.com - радовало то, что я открыл запылившийся код, запустил тесты и продолжил работу как будь-то бы и не отвлекался...