При реализации курсовой работы я использовал IDE Microsoft Visual Studio 2019.
IDE(Integrated Drive Electronics или же интегрированная среда разработки) – комплекс программных средств, используемый программистами для разработки программного обеспечения. Среда разработки включает в себя:
Суть IDE заключается в объединении нескольких компонентов для максимальной концентрации программиста на решении алгоритмических задач, без потерь времени на сохранение файла в текстовом редакторе, затем вызове компилятора и так далее. Таким образом, повышается производительность труда разработчика. Также огромным преимуществом среды разработки является наличие статического анализатора кода, который позволяет выявить ошибки в синтаксисе и другие мелкие ошибки по ходу написания программы.
Microsoft Visual Studio 2019 – это среда разработки от компании Microsoft. Она включает в себя поддержку многих компонентов таких как: Visual Basic, Visual C++, Visual C#, Python, .NET и её компоненты, имеет встроенный веб–сервер который может пригодиться при веб–разработке, присутствует интеграция с Unity и Unreal Engine. Можно разрабатывать как консольные приложения, так и приложения с графическим интерфейсом. Visual Studio позволяет создавать и подключать сторонние дополнения для расширения функциональности при помощи NuGet, также присутствует интеграция с системой контроля версий Git.
Основные возможности и преимущества программы:
3.2 Использование системы контроля версий GIT
Система контроля версий(СКВ) – это система, записывающая изменения в файл или набор файлов в течение времени и позволяющая вернуться позже к определённой версии. Она позволяет вернуть файлы к состоянию, в котором они были до изменений, вернуть проект к исходному состоянию, увидеть изменения, увидеть, кто последний менял что-то и вызвал проблему, кто поставил задачу и когда и многое другое.
Многие люди в качестве метода контроля версий применяют копирование файлов в отдельную директорию (возможно даже, директорию с отметкой по времени, если они достаточно сообразительны). Данный подход очень распространён из-за его простоты, однако он невероятно сильно подвержен появлению ошибок. Можно легко забыть, в какой директории вы находитесь, и случайно изменить не тот файл или скопировать не те файлы, которые вы хотели.
Для того, чтобы решить эту проблему, программисты разработали локальные СКВ с простой базой данных, которая хранит записи о всех изменениях в файлах, осуществляя тем самым контроль ревизий.
На рисунке 11 представлена схема локального контроля версий.
Рисунок 11 – Локальный контроль версий
Одной из популярных СКВ была система RCS, которая и сегодня распространяется со многими компьютерами. RCS хранит на диске наборы патчей (различий между файлами) в специальном формате, применяя которые она может воссоздавать состояние каждого файла в заданный момент времени.
Следующая серьёзная проблема, с которой сталкиваются люди, – это необходимость взаимодействовать с другими разработчиками. Для того, чтобы разобраться с ней, были разработаны централизованные системы контроля версий (ЦСКВ). Такие системы, как CVS, Subversion и Perforce, используют единственный сервер, содержащий все версии файлов, и некоторое количество клиентов, которые получают файлы из этого централизованного хранилища. Применение ЦСКВ являлось стандартом на протяжении многих лет.
На рисунке 12 представлена схема централизованного контроля версий.
Рисунок 12 – Централизованный контроль версий
Такой подход имеет множество преимуществ, особенно перед локальными СКВ. Например, все разработчики проекта в определённой степени знают, чем занимается каждый из них. Администраторы имеют полный контроль над тем, кто и что может делать, и гораздо проще администрировать ЦСКВ, чем оперировать локальными базами данных на каждом клиенте.
Несмотря на это, данный подход тоже имеет серьёзные минусы. Самый очевидный минус – это единая точка отказа, представленная централизованным сервером. Если этот сервер выйдет из строя на час, то в течение этого времени никто не сможет использовать контроль версий для сохранения изменений, над которыми работает, а также никто не сможет обмениваться этими изменениями с другими разработчиками.
Существуют распределённые системы контроля версий (РСКВ). В РСКВ (таких как Git, Mercurial, Bazaar или Darcs) клиенты не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени) – они полностью копируют репозиторий. В этом случае, если один из серверов, через который разработчики обменивались данными, умрёт, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Каждая копия репозитория является полным бэкапом всех данных.
На рисунке 13 изображена схема распределённого контроля версий.
Рисунок 13 – Распределённый контроль версий
Более того, многие РСКВ могут одновременно взаимодействовать с несколькими удалёнными репозиториями, благодаря этому разработчики могут работать с различными группами людей, применяя различные подходы единовременно в рамках одного проекта. Это позволяет применять сразу несколько подходов в разработке, например, иерархические модели, что совершенно невозможно в централизованных системах.
В нашем курсовом проекте использовался онлайн-репозиторий GitHub. Ссылка на него: https://github.com/dmitrysavitski/Shoes-store