В моем понимании, упущен один из важных уровней развития — понимание, что программирование не только про код, архитектуру и разработку.
Говоря в терминах статьи — это еще более высокий уровень. Уровень осознания задачи и понимания ее значения в бизнесе. Именно это понимание останавливает человека от того, чтобы писать код ради самого кода.
Этот этап становления программиста, мне кажется одним из самых ключевых.
А в остальном — идея статьи очень интересна, спасибо.
Со своей стороны хочу добавить про то, что сейчас Qt — это больше QML, нежели C++. Конечно, с мобильными платформами все посложнее будет, но ситуация постепенно улучшается. Я все же надеюсь на появление библиотек нормального качества для работы с API мобильных платформ. А то прокидывать, например, все через JNI — то еще удовольствие.
Что мне нравится в QML, так это внятная декларативность. А в случае, когда декларативности не хватает — можешь писать на JavaScript. И то и другое может освоить даже дизайнер. Таким образом, можно иметь одного опытного чувака, который будет работать на C++ glue и предоставлять все нужное для QML. А в QML могут работать люди, которые знакомы с JS, или даже дизайнеры. Например подкрутить анимации или накидать экран — реально просто.
На счет подгона под Look&Feel платформы — все так. Это может быть та еще боль и страдания. Один скролл чего стоит.
В целом, вся бизнес-логика мета-игры должна быть отвязана от Unity-классов. Тогда написать Unit тесты не составит проблем. Чтобы начать unit-тестить можно попробовать туторы от Unity.
Идея в том, чтобы Unity был только прослойкой для вызова соответствующих методов. Тогда после написания бизнес-правил и unit-тестов, все что останется — привязать соответствующие вызовы из UI.
Если тесты написаны правильно, то все должно работать как часы. И проблемы могут быть только на стороне UI или взаимодействия с сервером.
Плюс ко всему можно прикрутить проверку тестов к вашему билд-пайплайну. Собирается билд, сразу запускается проверка тестов. Если все ок — можете быть спокойны, что хотя бы протестированная часть игры будет работать правильно.
Помимо Unit-тестов можно так же сделать интеграционные тесты. Например, я тестировал интграцию с facebook, получив руками токен, и запуская тесты, которые дергали разные API методы FB и проверяли, что наш код работает ок.
Такие штуки могут так же позволить отловить проблемы, когда инеграция со сторонним сервисом отваливается.
Но в принципе, unit-тесты самый простой и быстрый способ.
Я первое время тоже шел по пути «не хватает рук», но потом понял, что тестировать Unit-тестами всякую логику для meta-игры гораздо проще. Не каждый раз запускать игру и проверять. С геймплеем, конечно, все посложнее будет. Но это точно никак меня не замедлило, скорее наоборот.
Вижу что вы очень серьезно относитесь к качеству и тестированию. По моему опыту ручное тестирование может выявить дай бог 10% багов.
Интересно, проводите ли вы только ручное тестирование, или же еще пользуетесь автоматизированным? (Unit тесты, игровые боты и т.д.). Например, мне, в свое время, очень помог игровой бот, который выявлял проблемы с уровнями, которые были только на определенных устройствах.
Будет интересно узнать как у вас с этим дела. Я заметил тенденцию, что многие инди не учитывают, что в случае успеха, их юзербаза резко вырастет и все может загнуться :). Именно поэтому важно проектировать игру с учетом этих особенностей. Потом оптимизировать и переделывать будет гораздо сложнее. А возможно и слишком поздно.
Большинство менеджеров разработки, с которыми я сталкивался, понятия не имеют как эту самую разработку менеджить. Да и вообще плохо понимают что такое менеджмент.
Вообще, во всех организациях, кроме благотварительных, цель — получение прибыли. Agile как раз про это, ведь он позволяет оперативно реагировать на изменения рынка/требований. Внедрять Agile сложно в организациях, где правят староверы или где разработка — не основной вид деятельности.
Конечно сложно сдвинуть что-то гигантское. Но положительный тренд уже прослеживается. Если банки смотрят в эту сторону, то значит Agile может отвечать всем требованиям качества/безопасности.
Кстати, еще вспомнил про Альфа-банк. Они не так давно писали про их Agile.
Кстати, я заметил, что слишком много людей в менеджменте не имеют представления что это такое. Не имеют профильного образования. Не желают слушать и учиться. От того и помехи :(.
И толковый менеджер должен в этой ситуации не «продавить», а спросить «а как мы можем сделать чтобы это было на один пиксел левее?»
Согласен. Но и толковый программист, если заинтересован в успехе проекта, должен предложить альтернативные решения.
Вообще, так как программист лучше всего осведомлен о текущем состоянии проекта, мне кажется, это обязанность программиста — предупреждать о возможных рисках/проблемах, и предлагать варианты решения. Менеджер же не должен пропускать это мимо ушей, должен принимать конкретные решения и дейтвовать.
Проблема отсутствия уважения существуют с двух сторон. Программисты тоже часто не уважают менеджеров просто за тот факт, что они менеджеры. Но в целом я согласен. В этом плане CTO во многом может на все влиять.
Просто посмотрите кто придумал эти методологии. http://agilemanifesto.org/authors.html
Лично мне кажется, что они изначально разрабатывались в помощь программистам. Но все их понимали по-своему и модифицировали, Эти же парни (авторы agile manifesto) были поражены, что появилась такая вещь, как Dark Scrum.
Возможно и мы сами их понимаем неправильно, боясь облажаться перед начальством.
Я работал в геймдеве и прекрасно понимаю о каких переработках идет речь. И я проходил через этот этап, когда я давал оценку, но не мог уложиться, работал на выходных. В конце концов я поговорил со своим менеджером и он меня отругал за это. Сказал, что это не правильно, и нужно корректировать оценку. Или переносить задачу на другой спринт.
Поэтому я могу сделать вывод, что это все зависит от начальства. Хотя и мы сами, если будем говорить о проблемах, можем повлиять на их точку зрения.
а возможностей Amazon Athena недостаточно?
Говоря в терминах статьи — это еще более высокий уровень. Уровень осознания задачи и понимания ее значения в бизнесе. Именно это понимание останавливает человека от того, чтобы писать код ради самого кода.
Этот этап становления программиста, мне кажется одним из самых ключевых.
А в остальном — идея статьи очень интересна, спасибо.
Что мне нравится в QML, так это внятная декларативность. А в случае, когда декларативности не хватает — можешь писать на JavaScript. И то и другое может освоить даже дизайнер. Таким образом, можно иметь одного опытного чувака, который будет работать на C++ glue и предоставлять все нужное для QML. А в QML могут работать люди, которые знакомы с JS, или даже дизайнеры. Например подкрутить анимации или накидать экран — реально просто.
На счет подгона под Look&Feel платформы — все так. Это может быть та еще боль и страдания. Один скролл чего стоит.
Идея в том, чтобы Unity был только прослойкой для вызова соответствующих методов. Тогда после написания бизнес-правил и unit-тестов, все что останется — привязать соответствующие вызовы из UI.
Если тесты написаны правильно, то все должно работать как часы. И проблемы могут быть только на стороне UI или взаимодействия с сервером.
Плюс ко всему можно прикрутить проверку тестов к вашему билд-пайплайну. Собирается билд, сразу запускается проверка тестов. Если все ок — можете быть спокойны, что хотя бы протестированная часть игры будет работать правильно.
Помимо Unit-тестов можно так же сделать интеграционные тесты. Например, я тестировал интграцию с facebook, получив руками токен, и запуская тесты, которые дергали разные API методы FB и проверяли, что наш код работает ок.
Такие штуки могут так же позволить отловить проблемы, когда инеграция со сторонним сервисом отваливается.
Но в принципе, unit-тесты самый простой и быстрый способ.
Интересно, проводите ли вы только ручное тестирование, или же еще пользуетесь автоматизированным? (Unit тесты, игровые боты и т.д.). Например, мне, в свое время, очень помог игровой бот, который выявлял проблемы с уровнями, которые были только на определенных устройствах.
Успехов с проектом!
Это очень печально.
Кстати, еще вспомнил про Альфа-банк. Они не так давно писали про их Agile.
Согласен. Но и толковый программист, если заинтересован в успехе проекта, должен предложить альтернативные решения.
Вообще, так как программист лучше всего осведомлен о текущем состоянии проекта, мне кажется, это обязанность программиста — предупреждать о возможных рисках/проблемах, и предлагать варианты решения. Менеджер же не должен пропускать это мимо ушей, должен принимать конкретные решения и дейтвовать.
Лично мне кажется, что они изначально разрабатывались в помощь программистам. Но все их понимали по-своему и модифицировали, Эти же парни (авторы agile manifesto) были поражены, что появилась такая вещь, как Dark Scrum.
Возможно и мы сами их понимаем неправильно, боясь облажаться перед начальством.
Я работал в геймдеве и прекрасно понимаю о каких переработках идет речь. И я проходил через этот этап, когда я давал оценку, но не мог уложиться, работал на выходных. В конце концов я поговорил со своим менеджером и он меня отругал за это. Сказал, что это не правильно, и нужно корректировать оценку. Или переносить задачу на другой спринт.
Поэтому я могу сделать вывод, что это все зависит от начальства. Хотя и мы сами, если будем говорить о проблемах, можем повлиять на их точку зрения.