Gamedev + Git

На этапе проработки логики программы, уже возможно предусмотреть некоторые возможные ошибки, но задача в другом, понять, что должна делать программа "внутри" себя, чтобы пользователь получил тот результат, который ему необходим.

Если переложить это с разработки программного обеспечения на разработку автомобилей, то ты проектируешь расположение механизмов под капотом, расстояние между колес, высоту и расположение кресел, да и в целом понимание того, как то, что ты напридумывал на прошлом этапе, заставить работать.

И уже затем, ты начинаешь переносить логику в код. Ну или изготавливать детали, из которых будешь собирать автомобиль, если вдруг решил заняться автомобилестроением вместо разработки программного обеспечения, пока слушал меня.

Затем ты выпускаешь программу, а другие ее скачивают и начинают использовать.

И все бы было хорошо, если бы все пользователи твоей программы, перед ее использованием, прочитали руководство, как ей правильно пользоваться и при работе руководствовались бы им (минутка тавтологии), а еще лучше, думали также, как разработчик.

Но нет, пользователь может совершать то, о чем ты даже и не задумывался.

К тому же, при определенных условиях программа может просто неправильно обрабатывать данные, которые получает.

Например: пользователь захочет поделить на "ноль", а если говорить про автомобиль, раз уж начали, захочет на скорости 100 км\ч включить заднюю скорость или остановиться о дерево.

Скорее всего, результат будет так себе.

По этому, обычно, проводят предварительное тестирования.

Если ты следишь за играми, то скорее всего, слышал о бета-тестах, или же участвовал в таких.

Смысл таких тестов проверить работоспособность и выявить ошибки, при различных сценариях использования программы.

Анализируя полученные данные, ты можешь заблокировать некоторые действия, научить программу работать с нестандартными ситуациями и точнее настроить взаимодействие функций внутри твоей программы, да так, чтобы каждый раз программу не переписывать заново.

Для этого тебе нужно будет внести изменения в код, обновить программу - по сути, добавить в исходный код новый код, да так, чтобы то, что уже работает, продолжало работать.

Именно по этому современный разработчик использует системы контроля версий. Если ты играешь в танки достаточно долго, то возможно, помнишь, что первая версия появилась не сразу. Какой-то длительный промежуток времени игра выходила под версией 0.9 что-то там. Сам я играл 2 боя, и где-то у меня был аккаунт со 100% статистикой побед, как раз за эти 2 боя. Мне не зашло, да и разговор то не об этом, а о том, что разработчики выпустили продукт, который уже как-то работал, и собирая обратную связь и отчеты об ошибках от пользователей, допиливали игру до максимально рабочего состояния.

Используя системы контроля версий, всегда есть возможность вернуться назад, откатиться к предыдущим состояниям кода, если текущая версия работает некорректно, или отказаться от каких либо новых функций, которые просто не нужны.

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

Именно потому, что системы контроля версий позволяют возвращаться к предыдущему состоянию программы, а также безболезненно работать командой над одним проектом, такие системы приобрели широкую популярность.

Одним из представителей подобных решений является git - не путать с gitHub.

Но об этом не сегодня.

З.Ы. Не уверен, нужен ли тег "Мое", так как Симпсоны - не мое. Да и остальные картинки тоже.