Процесс программирования

• Единая структура проекта;
• Общие инструменты для работы с кодом;
• Общие принципы работы с кодом.

Структура проекта

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

Модули кода

• объединяются блоки кода, которые реализуют какое-то универсальное действие. Такие универсальные блоки в дальнейшем можно переиспользовать в другом приложении;
• объединяются блоки кода, которые выполняют определённый набор действий и неразрывно связаны между собой. Например, для того, чтобы приготовить ужин, вначале нужно купить все необходимые продукты.

• Повторно использовать модули в других приложениях: если какая-то из функций отделена в независимый от остальной программы блок, её можно переиспользовать в других программах и сэкономить время команды;
• Проще изменять или заменять модули: если блоки кода сильно зависят друг от друга, изменять его в разы сложнее, ведь придётся вносить изменения в несколько мест. Деление кода на независимые блоки позволяет упростить внесение изменений.

1. Каждый модуль помещён в отдельный файл или в несколько файлов, если это большой и сложный модуль.
2. Несколько модулей находятся в одном файле.

Инструменты для программирования

• интегрированную среду разработки (Integrated Development Environment (IDE));
• систему контроля версий (Version Control System (VCS)).

Интегрированная среда разработки

• Текстовый редактор, который используется для написания, редактирования и просмотра кода в удобной среде. В IDE осуществляется подсветка синтаксиса, автозаполнение в зависимости от выбранного языка программирования.
• Часть, включающая в себя ряд инструментов для запуска, тестирования и отладки кода, куда входит компилятор либо интерпретатор, средства автоматизации сборки и отладчик.
• Часть, включающая в себя возможность работы с системой контроля версий для управления проектом.

Пример интерфейса интегрированной среды разработки IntelliJ IDEA

Система контроля версий

• управления различными версиями кода. Это даёт возможность при необходимости восстановить более ранние версии кода;
• совместной работы над одним и тем же проектом, что позволяет безопасным образом работать с одними и теми же файлами исходного кода;
• отслеживания изменений. Система контроля версий позволяет просматривать, кто и что изменил в документе и когда это изменение было внесено.

• GIT
• Mercurial
• Bazaar.

В IntelliJ IDEA встроена система контроля версий GIT

Работа с системой контроля версий

Репозиторий

Создание нового проекта

git commit -m "Первый коммит" 

Процесс совместной работы

1. Первое, что необходимо сделать Косте, — это извлечь последнюю версию проекта из центрального репозитория (origin) с помощью команды pull (пул):
   Скопировать код

   git pull origin master 
   Здесь origin указывает на центральный репозиторий, а master означает основную ветку, содержимое которой необходимо получить.
2. Теперь у Кости есть последняя версия кода, и он может приступить к доработке. Но для этого ему необходимо создать новую ветку (branch), чтобы обеспечить безопасность всего проекта. Все изменения, которые он будет вносить, будут осуществляться в новой ветке, а в мастер ветке файл с кодом останется без изменений. Поэтому создание новой ветки при разработке имеет очень большое значение.
   Костя создаёт новую ветку с названием “favorite” и использует для этого следующую команду:
   Скопировать код

   git branch favorite 
   Новая ветка является точной копией ветки, из которой её создали. В нашем примере Костя создал копию мастер ветки. Чтобы начать работу над кодом, недостаточно просто создать новую ветку. Следующим шагом необходимо переключится на нужную ветку, используя команду “checkout”.
   Скопировать код

   git checkout favorite 
   Так будет выглядеть создание новой ветки в git, где кружком в новой ветке будет обозначаться первоначальная версия кода:
   
3. Костя внёс необходимые изменения в код исходного файла. Теперь ему нужно зафиксировать изменения в системе контроля версий. Для этого необходимо сделать новый коммит. В этом случае коммит в новой ветке будет выглядеть так:
   
4. Теперь у Кости есть два пути:

   • Если он по какой-то причине решил, что внесённые им изменения никуда не годятся, он может просто переключиться на ветку мастер, и файл с исходным кодом останется без изменений.
   • Если он доволен написанным кодом, то необходимо объединить две ветки. Для этого надо переключиться на ветку мастер и использовать для этого команду merge:
   Скопировать код

    git merge new
     
   Разработчики могут называть это действие смерджить, это означает, что изменения, внесенные в ветку, в которой работал Костя, объединяются с содержимым ветки мастер. Это можно проиллюстрировать следующим:
   
5. На данном этапе все сделанные Костей изменения находятся в мастере, но всё ещё хранятся в локальном репозитории. Никто из других разработчиков, работающих над проектом, их не увидит. Это значит, что дальше необходимо перенести сделанные изменения в центральный репозиторий.
   Однако прежде чем сделать это, необходимо убедиться, что в центральном репозитории не были внесены никакие другие изменения другими разработчиками. Поэтому сначала необходимо извлечь все изменения из центрального репозитория с помощью той же команды, с которой всё начиналось:
   Скопировать код

   git pull origin master 
6. Если с момента последнего извлечения с центральным репозиторием ничего не произошло, то никакие изменения в локальном репозитории не произойдут. Это значит, что теперь можно внести сделанные изменения с помощью следующей команды push:
   Скопировать код

   git push origin master 
   После того как код «запушен», все новые изменения находятся в центральном репозитории. И локальная версия ветки мастер, и версия, хранящаяся в центральном репозитории, будут идентичны друг другу.
7. Однако с момента последнего извлечения разработчик Миша, который работал над добавлением кнопки «Поделиться» в карточку товара, успел внести изменения в центральный репозиторий. Он внёс изменения в тот же файл и в то же место, что и Костя. Поэтому Косте придётся иметь дело с конфликтом слияния (merge conflict). В файле с кодом он увидит следующее:
   Скопировать код

   исходный код, который был в мастер ветке
   <<<<<<< HEAD
   код, добавленный Мишей
   =======
   код, добавленный Костей
   >>>>>>> div 
   Маркер <<<<<<< HEAD указывает на начало конфликта. То, что находится между этой строкой и строкой =======, — это код, который добавил Миша. Код между ======= и >>>>>>> div — это изменения Кости.
8. Если Костя решает, что обе функции должны быть в этом файле, он удаляет три строки-маркера из файла. Теперь это выглядит следующим образом:
   Скопировать код

   исходный код, который был в мастер ветке
   код, добавленный Мишей
   код, добавленный Костей 
9. Теперь Костя может внести сделанные изменения с помощью команды push, и оба кода будут добавлены в центральный репозиторий.

Развёртывание написанного кода

1. В первую очередь код тестируется в среде разработки.
2. Затем код попадает в тестовую среду, где тестируется тестировщиками.
3. Если тестирование пройдено успешно, код развертывается на продуктивной среде.

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

Подведём итоги

• Интегрированная среда разработки (Integrated Development Environment (IDE)) IDE используется для написания, редактирования и просмотра кода, а также для его запуска, тестирования и отладки.
• Система контроля версий (Version Control System (VCS)) VCS используется для управления различными версиями кода, совместной работы над одним проектом и отслеживания изменений.

1. В первую очередь код тестируется в среде разработки.
2. Затем код попадает в тестовую среду, где тестируется тестировщиками.
3. Если тестирование успешно пройдено, то код развёртывается на продуктивной среде.