Современный пользователь, запуская приложение\программу\игру\что угодно, на своем компьютере, хочет быть уверенным, даже не так, совершенно не задумывается о том, что в приложении могут быть ошибки\баги\глюки, называй, как угодно, а задача разработчика выпустить продукт таким, чтобы эти самые ошибки и не возникали.
Как это работает:
Сначала разрабатывается идея приложения.
Затем разрабатывается логика его работы.
А после уже логика переносится в код.
Я должен оговориться, что это сильно упрощенная схема, однако, смысл всех этапов разработки примерно такой.
Ну согласись, когда у тебя есть только "Эта программа будет текстовым редактором с подсветкой ссылок и отображением их содержимого в правом углу"
- вряд ли ты задумаешься над тем, какие ошибки в работе могут происходить - ты просто описываешь будущий текстовый редактор.
Ты не будешь думать о том, что делать, если пользователь захочет открыть в нем mp3 файл или картинку. Нет, ты просто описываешь свое видение программы.
На этом этапе ты занимаешься только этим, и ни чем другим.
Если переложить это на разработку автомобиля, то ты описываешь автомобиль - автомобиль будет с круглыми окнами, отдельным отсеком для детей и тещи, будет играть кукарачу вместо гудка, и... ну примерно, как тут:
На этапе проработки логики программы, уже возможно предусмотреть некоторые возможные ошибки, но задача в другом, понять, что должна делать программа "внутри" себя, чтобы пользователь получил тот результат, который ему необходим.
Если переложить это с разработки программного обеспечения на разработку автомобилей, то ты проектируешь расположение механизмов под капотом, расстояние между колес, высоту и расположение кресел, да и в целом понимание того, как то, что ты напридумывал на прошлом этапе, заставить работать.
И уже затем, ты начинаешь переносить логику в код. Ну или изготавливать детали, из которых будешь собирать автомобиль, если вдруг решил заняться автомобилестроением вместо разработки программного обеспечения, пока слушал меня.
Затем ты выпускаешь программу, а другие ее скачивают и начинают использовать.
И все бы было хорошо, если бы все пользователи твоей программы, перед ее использованием, прочитали руководство, как ей правильно пользоваться и при работе руководствовались бы им (минутка тавтологии), а еще лучше, думали также, как разработчик.
Но нет, пользователь может совершать то, о чем ты даже и не задумывался.
К тому же, при определенных условиях программа может просто неправильно обрабатывать данные, которые получает.
Например: пользователь захочет поделить на "ноль", а если говорить про автомобиль, раз уж начали, захочет на скорости 100 км\ч включить заднюю скорость или остановиться о дерево.
Скорее всего, результат будет так себе.
По этому, обычно, проводят предварительное тестирования.
Если ты следишь за играми, то скорее всего, слышал о бета-тестах, или же участвовал в таких.
Смысл таких тестов проверить работоспособность и выявить ошибки, при различных сценариях использования программы.
Анализируя полученные данные, ты можешь заблокировать некоторые действия, научить программу работать с нестандартными ситуациями и точнее настроить взаимодействие функций внутри твоей программы, да так, чтобы каждый раз программу не переписывать заново.
Для этого тебе нужно будет внести изменения в код, обновить программу - по сути, добавить в исходный код новый код, да так, чтобы то, что уже работает, продолжало работать.
Именно по этому современный разработчик использует системы контроля версий. Если ты играешь в танки достаточно долго, то возможно, помнишь, что первая версия появилась не сразу. Какой-то длительный промежуток времени игра выходила под версией 0.9 что-то там. Сам я играл 2 боя, и где-то у меня был аккаунт со 100% статистикой побед, как раз за эти 2 боя. Мне не зашло, да и разговор то не об этом, а о том, что разработчики выпустили продукт, который уже как-то работал, и собирая обратную связь и отчеты об ошибках от пользователей, допиливали игру до максимально рабочего состояния.
Используя системы контроля версий, всегда есть возможность вернуться назад, откатиться к предыдущим состояниям кода, если текущая версия работает некорректно, или отказаться от каких либо новых функций, которые просто не нужны.
Особенно актуально вопрос контроля версий стоит в случае коллективной работы над одним проектом.
Каждый участник может предлагать свои изменения в программу, без вреда рабочей версии. После одобрения принимающим решение участником, такие изменения можно внести в новую версию.
Именно потому, что системы контроля версий позволяют возвращаться к предыдущему состоянию программы, а также безболезненно работать командой над одним проектом, такие системы приобрели широкую популярность.
Одним из представителей подобных решений является git - не путать с gitHub.
Но об этом не сегодня.
З.Ы. Не уверен, нужен ли тег "Мое", так как Симпсоны - не мое. Да и остальные картинки тоже.
