Разрабатываю игру BoomTris.
Открыл и поиграл в неё. Вполне интересная несмотря на 4 года разработки (последние 2 в замедленном режиме).
Пытался понять в чём дело и что дальше делать - заглянул в HackNPlan и Trello.
Множество задач демотивирует. Даже текущие, которые видны в работе ничего не дают.
Понял, что нужно их расписывать детально - будущий я скажет за это спасибо. А так - короткое описание и ничего нет. И смотришь как "баран на новые ворота".
И думаешь: "Зачем я это сделал? И что за ошибка? Как возникает, что надо сделать?"
Вот тут приходит демотивация. И чтобы её обойти достаточно сбросить все задачи (всё равно - раз забылись, значит их и нет) и добавить новые или найти ту, которую сейчас видишь и работать относительно её.
Когда открыл код и просто посмотрел где происходит замена башен в сетке на большую , то заметил, что он сложный. Анализ кода показывает, что коэффициент поддерживаемости 56, что не очень хорошо.
Пришлось рефакторить и вынести методы. Поднялся коэффициент до 70 после этого.
Причём самое сложное - не цикломатическая сложность (предпочитаю сложные алгоритмы не делать - сам потом не разберёшь что и зачем), а связность классов.
Мой класс TowerController связан со многими. Но как его уменьшить даже не представляю.
Как в книге "Шаг за шагом к достижению цели" рассказано, что надо задавать простые вопросы и делать простые шаги. И это реально помогает.
Для меня сейчас самое сложное - понять как это работает и почему глюки происходят. Когда просто сидишь и думаешь, что же сделать? То приходишь к тому, что в голове пусто - это проснулся центр страха.
А когда просто открываешь редактор и ползаешь по коду - многое видишь. Сам рефакторинг даёт ощущение прогресса без самого прогресса (только улучшается качество кода - так вполне хороший прогресс).
Где можно использую тесты. Но в Unity они не очень удобные. Она отказывается запускать тесты из среды, если есть хоть одна ссылка на её компоненты. А из редактора это не очень то удобно. Да и навигация к месту проблемы тоже не из лучших.
Самое забавное - код, который написал использует шаблон "Подписка" во всех возможных классах (от жизни до башен и сетки). И вот отладить это достаточно сложно.
Хорошо ещё Visual Studio позволяет пройтись по всем местам пошагово или расставить точки останова.
Излишняя или ранняя общность даёт отрицательный результат и эффективность работы падает. Думать о расширяемости надо с начала, но двигаться туда надо медленно.
Иначе сложность поглотит и ничего не останется.
Как в Бруксе "Мистический человеко-месяц" метафора асфальтового озера: "Можно вытащить одну ногу, но все остальное погружается, и ни гигант ни маленькое создание не может с этим справиться"
Учитывая, что мой мозг имеет весьма ограниченный размер - то борьба со сложностью выходит на первый план. И использовать архитектурные шаблоны - вещь хорошая (особенно, когда есть документация), но надо быть осмотрительнее.
Отладка может превратиться в кошмар.
Создание тестовых утилит тоже сложная вещь. И часто сидишь и смотришь на код с пустой головой. Но когда просто начинаешь делать (как в молодости) и код сам льётся из под пальцев.
Испробовав разные методы пришёл к тому, что логирование и вывод на экран в отладочном режиме вполне хорош. Тратить время на создание специализированного инструмента окупится при длительной разработке.
Думаю - стоит сделать отладочный инструмент для сетки.
Асинхронное падение блоков, несмотря на то, что ушёл от физики в сторону своего движка перемещения - всё равно отлаживать сложно.
После попыток создания такого движка как в матч-3 стал уважать программистов "Treasures of Montezuma" ещё больше - у них там на вид полная ассинхронность падения и действий.
После стольких лет возникает желание переписать код с нуля без ассинхронности с полным
контролем того, что происходит. Но приходит понимание, что это затянет разработку надолго.
Поэтому оставляю это на 2ю версию. Надо просто выложить игру и доделать.
Потом можно будет нанять помощников для отладки.
Как говорил Ритчи создатель языка С: "Для отладки надо в два раза более мощный разум.
Поэтому, если вы используете весь свой интеллект для создания сложного и хитроумного
кода, то по определению вы не сможете его отладить сами"
Вот так игра со сложностью обернулась мне боком.
И главное - видеть проблему, принять её и начать пошагово исправлять.
Открыл и поиграл в неё. Вполне интересная несмотря на 4 года разработки (последние 2 в замедленном режиме).
Пытался понять в чём дело и что дальше делать - заглянул в HackNPlan и Trello.
Множество задач демотивирует. Даже текущие, которые видны в работе ничего не дают.
Понял, что нужно их расписывать детально - будущий я скажет за это спасибо. А так - короткое описание и ничего нет. И смотришь как "баран на новые ворота".
И думаешь: "Зачем я это сделал? И что за ошибка? Как возникает, что надо сделать?"
Вот тут приходит демотивация. И чтобы её обойти достаточно сбросить все задачи (всё равно - раз забылись, значит их и нет) и добавить новые или найти ту, которую сейчас видишь и работать относительно её.
Когда открыл код и просто посмотрел где происходит замена башен в сетке на большую , то заметил, что он сложный. Анализ кода показывает, что коэффициент поддерживаемости 56, что не очень хорошо.
Пришлось рефакторить и вынести методы. Поднялся коэффициент до 70 после этого.
Причём самое сложное - не цикломатическая сложность (предпочитаю сложные алгоритмы не делать - сам потом не разберёшь что и зачем), а связность классов.
Мой класс TowerController связан со многими. Но как его уменьшить даже не представляю.
Как в книге "Шаг за шагом к достижению цели" рассказано, что надо задавать простые вопросы и делать простые шаги. И это реально помогает.
Для меня сейчас самое сложное - понять как это работает и почему глюки происходят. Когда просто сидишь и думаешь, что же сделать? То приходишь к тому, что в голове пусто - это проснулся центр страха.
А когда просто открываешь редактор и ползаешь по коду - многое видишь. Сам рефакторинг даёт ощущение прогресса без самого прогресса (только улучшается качество кода - так вполне хороший прогресс).
Где можно использую тесты. Но в Unity они не очень удобные. Она отказывается запускать тесты из среды, если есть хоть одна ссылка на её компоненты. А из редактора это не очень то удобно. Да и навигация к месту проблемы тоже не из лучших.
Самое забавное - код, который написал использует шаблон "Подписка" во всех возможных классах (от жизни до башен и сетки). И вот отладить это достаточно сложно.
Хорошо ещё Visual Studio позволяет пройтись по всем местам пошагово или расставить точки останова.
Излишняя или ранняя общность даёт отрицательный результат и эффективность работы падает. Думать о расширяемости надо с начала, но двигаться туда надо медленно.
Иначе сложность поглотит и ничего не останется.
Как в Бруксе "Мистический человеко-месяц" метафора асфальтового озера: "Можно вытащить одну ногу, но все остальное погружается, и ни гигант ни маленькое создание не может с этим справиться"
Учитывая, что мой мозг имеет весьма ограниченный размер - то борьба со сложностью выходит на первый план. И использовать архитектурные шаблоны - вещь хорошая (особенно, когда есть документация), но надо быть осмотрительнее.
Отладка может превратиться в кошмар.
Создание тестовых утилит тоже сложная вещь. И часто сидишь и смотришь на код с пустой головой. Но когда просто начинаешь делать (как в молодости) и код сам льётся из под пальцев.
Испробовав разные методы пришёл к тому, что логирование и вывод на экран в отладочном режиме вполне хорош. Тратить время на создание специализированного инструмента окупится при длительной разработке.
Думаю - стоит сделать отладочный инструмент для сетки.
Асинхронное падение блоков, несмотря на то, что ушёл от физики в сторону своего движка перемещения - всё равно отлаживать сложно.
После попыток создания такого движка как в матч-3 стал уважать программистов "Treasures of Montezuma" ещё больше - у них там на вид полная ассинхронность падения и действий.
После стольких лет возникает желание переписать код с нуля без ассинхронности с полным
контролем того, что происходит. Но приходит понимание, что это затянет разработку надолго.
Поэтому оставляю это на 2ю версию. Надо просто выложить игру и доделать.
Потом можно будет нанять помощников для отладки.
Как говорил Ритчи создатель языка С: "Для отладки надо в два раза более мощный разум.
Поэтому, если вы используете весь свой интеллект для создания сложного и хитроумного
кода, то по определению вы не сможете его отладить сами"
Вот так игра со сложностью обернулась мне боком.
И главное - видеть проблему, принять её и начать пошагово исправлять.
