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

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

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

Чтобы избежать хаоса и иметь отлаженный механизм разработки, разработчики используют определенный набор инструментов, помогающих организовать командную работу:

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

Задание

·       Перечислить основные элементы методологии разработки ПО и описать что включает каждый элемент.

·       Перечислить и описать виды методологий разработки ПО.

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

Задание

·       Перечислить и описать структуру плана проекта (элементы, из которых состоит план проекта)

·          Средства автоматизации групповой работы - позволяют наладить эффективную коммуникацию между членами команды, особенно в случае, когда они не работают в одном офисе.  Эта система доступна группе разработчиков и содержит календарь, адресный справочник, средство планирования совещаний, механизм для совместного доступа и хранения документации. Некоторые из таких систем могут иметь возможность проводить телеконференции, вебинары, делать тематические форумы.

Задание

·       Перечислить и описать примеры средств автоматизации групповой работы (Что включают и какие функции реализуют)

·          Система управления версиями или система контроля версий, - ПО, позволяющее вести совместную разработку кода. Оно дает возможность проанализировать, кто, чем и когда занимается, управлять модификациями кода, делать откат ошибочных вариантов и получать последнюю версию кода.

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

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

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

 То есть система контроля версий (СКВ) — это система, которая позволяет регистрировать изменения в одном или нескольких файлах проекта, с тем, чтобы в дальнейшем была возможность вернуться к определённым старым версиям этих файлов..

Она предоставляет следующие возможности:

·          хранение нескольких версий одних и тех же файлов проекта (возврат к определенным версиям файлов проекта, сделанным ранее, получение последних, актуальных на данный момент версий файлов проекта)

·          фиксация, кто и когда сделал изменение

·          синхронизация работы команды по объединению изменений, выполненных разными разработчиками.

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

Существуют разные типы СКВ :

1. По типу хранения информации и возможностям ее получения выделяют примитивную модель, локальные, централизованные и децентрализованные СКВ.

Примитивная модель хранения версий - актуальные копии проекта перезаписываются в отдельную директорию через определённый промежуток времени.

Достоинства:

— возможность восстановления данных одной из записанных версий.

Недостатки:

— сложности с поиском необходимой версии в обширной и плохо структурированной базе данных;

— возможность потери данных вследствие возникновения физических поломок оборудования;

— отсутствие возможности совместной разработки.

ПРИВЕСТИ ПРИМЕР

Локальная СКВ -  имеет базу данных на локальном компьютере пользователя, где хранятся версии разрабатываемого программного продукта (рис. 2).

Достоинства:

—   возможность восстановления данных из определенной версии;

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

Недостатки:

— возможность потери данных вследствие возникновения физических поломок оборудования;

— отсутствие возможности совместной разработки.

ПРИВЕСТИ ПРИМЕР

Централизованная СКВ - характеризуется наличием центрального сервера, на котором хранятся версии файлов (рис. 3). Разработчики и заинтересованные лица могут обращаться с запросами на сервер для получения информации.

Достоинства:

— возможность восстановления данных из определенной версии;

— возможность ведения командной разработки проекта;

Недостатки

 — возможность отсутствия доступа к серверу при неполадках,

— неисправность сервера и возможная потеря информации.

— низкая скорость работы (из-за возникновения сетевых задержек).

ПРИВЕСТИ ПРИМЕР

Децентрализованные, или распределенные СКВ, - в отличие от централизованных разработчики не просто выгружают последние версии файлов, а полностью копируют весь репозиторий.

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

Каждая копия содержит все данные, хранящиеся в удалённом репозитории. В случае, возникновения технической неисправности на стороне сервера, удаленный репозиторий можно перезаписать с любой сохраненной копии.

Репозиторий проекта есть у каждого разработчика.

При этом можно выделить центральный репозиторий, в который разработчики отправляют изменения своих локальных репозиториев, а последние синхронизируются с центральным (рис. 4).

Достоинства

— возможность восстановления данных из определенной версии;

— высокая надежность, гибкость и автономность отдельного рабочего места

— возможность работать с несколькими удаленными репозиториями

— возможность ведения командной разработки проекта;

— экономия затрат времени при выполнении большинства операций.

ПРИВЕСТИ ПРИМЕР

2. По принципу внесения изменений выделяют блокирующие и неблокирующие СКВ.

Блокирующие СКВ - разработчик, изменяющий файл, сообщает системе о желании его отредактировать. Файл открывается в режиме записи только для этого разработчика, а остальным членам команды данный файл будет доступен только в режиме чтения до тех пор, пока изменения не будут внесены и блокировка не снята.

Преимущества — отсутствие конфликтов при изменении кода;

Недостаток —задержка работы над тем или иным файлом проекта.

ПРИВЕСТИ ПРИМЕР

Неблокирующие СКВ -  один файл может изменяться одновременно несколькими разработчиками.

Модификации файлов объединяются при внесении их в систему. По умолчанию выполняется автоматическое объединение. Во время этого процесса могут возникнуть конфликты. В этом случае разработчику необходимо выполнить объединение вручную, что может стать трудоемкой задачей.

Преимущество — совместная работа над определенным файлом и экономия времени в случае отсутствия конфликтов;

Недостатки — возможность возникновения конфликтов и необходимость временных затрат на объединение вручную.

ПРИВЕСТИ ПРИМЕР

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

Совместимость и использование инструментов ревьюирования в различных системах контроля версий

По экспертным оценкам, главными мотивами использования СКВ были следующие:

·          общее, удобное, безопасное хранение исходных кодов с историей изменений

·           коллективное владение кодом;

·          разделение задач и функционала приложения внутри команды;

·          автоматизация сборок, развертывания и вообще непрерывная интеграция;

·          оптимизация командной разработки

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

На выбор СКВ влияют следующие факторы:

·          поддержка ядра СКВ и ее конкретной реализации;

·          знакомство команды разработчиков с тем или иным ПО; <

·           популярность той или иной системы;

·           соответствие возможностей СКВ принятому в команде процессу разработки

В заключение отметим, что согласно экспертным оценкам одной из самых перспективных и удобных СКВ, в том числе с точки зрения использования инструментов ревьюирования, была признана GIT.

Задание

Перечислить и описать примеры  систем управления версиями

1. GIT  - распределенная СКВ, разработана в 2005г.

2. SVN (Subversion) - централизованная СКВ, разработана в 2002г.

3. Mercurial  - распределенная СКВ, разработана в 2005г.

4. СVS - централизованная СКВ, разработана в 1990г.

5. Team Foundation server - централизованная СКВ, разработана в 2005г.

6. Bazaar - распределенная СКВ, разработана в 2004 г.

7. Perforce

8. Monotone

9. Darcs

·          Общее описание

·          Функциональные возможности

·          Достоинства и недостатки

·          Принцип работы

·          Инструкция по работе

·          Иллюстративный материал

КОНТРОЛЬНЫЕ ВОПРОСЫ ПО ЛЕКЦИИ 7

1.    Что входит в основной набор инструментов, необходимых для организации командной работы программистов?

2.    Какова основная цель использования методологии разработки в проекте?

3.    Что такое план проекта и какие элементы он в себя включает?

4.    Какие функции выполняют средства автоматизации групповой работы?

5.    Приведите примеры средств автоматизации групповой работы и опишите их ключевые возможности.

6. Дайте определение системе контроля версий (СКВ).

7. Какие три основные возможности предоставляет система контроля версий разработчикам?
8. Какой тип информации, помимо исходного кода, может храниться в СКВ?

9. Назовите два основных критерия, по которым классифицируются системы контроля версий.
10. Каковы, согласно лекции, главные мотивы использования СКВ в разработке?

11. Опишите примитивную модель хранения версий. Каковы её главные недостатки?
12. Чем характеризуется локальная СКВ? Назовите её основной недостаток.
13. Что такое централизованная СКВ и в чём заключается её главный риск?
14. Дайте определение распределённой (децентрализованной) СКВ.

15. Какое ключевое преимущество распределённой СКВ перед централизованной с точки зрения надёжности?
16. Почему в распределённой системе каждый разработчик имеет полную копию репозитория?

17. В чём заключается основной принцип работы блокирующих СКВ?

18. Какое основное преимущество и какой недостаток у блокирующей модели?
19. Как работает неблокирующая СКВ при одновременном изменении файла несколькими разработчиками?
20. Что такое "конфликт" в неблокирующей СКВ и как он разрешается?

21. Сравните блокирующий и неблокирующий подходы с точки зрения скорости работы и потенциальных сложностей.

22. Приведите по два примера централизованных и распределённых систем контроля версий.
23. Почему, согласно экспертам, Git была признана одной из самых перспективных СКВ?
24. Какие факторы влияют на выбор конкретной системы контроля версий для проекта?
25. Какую проблему решает наличие "центрального репозитория" в распределённой системе на практике?
26. Что подразумевается под "автоматическим объединением" изменений в неблокирующих СКВ?

27. Почему в локальной СКВ скорость выполнения операций выше, чем в централизованной?
28. Какой тип СКВ (блокирующая или неблокирующая) лучше подходит для работы с бинарными файлами (например, изображениями), которые сложно сравнивать и объединять? Обоснуйте ответ.
29. Какая из рассмотренных моделей хранения версий (примитивная, локальная, централизованная, распределённая) наименее пригодна для современной командной разработки и почему?

30. Опишите типичный рабочий процесс разработчика в распределённой неблокирующей СКВ (например, Git), начиная с получения последних изменений и заканчивая отправкой своей работы.

31. Сравнительный анализ архитектур. Чем архитектура распределённой СКВ (например, Git) принципиально отличается от централизованной (например, SVN) с точки зрения модели данных и истории изменений? Почему в Git операция commit выполняется локально, а в SVN требует обязательного взаимодействия с сервером?

32. Разрешение конфликтов как процесс. Опишите пошаговый алгоритм действий разработчика в неблокирующей СКВ (на примере Git) при возникновении конфликта слияния (merge conflict). Какие инструменты и команды используются на каждом этапе, от обнаружения конфликта до его финального разрешения и коммита?

33. Влияние модели СКВ на процесс разработки. Как выбор между блокирующей и неблокирующей СКВ может повлиять на организацию workflow в команде? Сравните два подхода с точки зрения скорости разработки, частоты интеграции и уровня коммуникации, необходимой между разработчиками.

34. Эволюция СКВ и причины смены парадигм. Исторически развитие шло от локальных и централизованных систем к распределённым. Какие фундаментальные проблемы первых двух архитектур (например, риск потери истории, необходимость постоянного подключения к сети) решает распределённая модель, сделавшая её современным стандартом?

35. Интеграция СКВ в CI/CD. Каким образом система контроля версий, в частности Git, интегрируется в процессы непрерывной интеграции и развёртывания (CI/CD)? Какой механизм (например, хуки - hooks) позволяет автоматически запускать сборку или тесты при поступлении новых изменений в определённую ветку репозитория?

36. Стратегии ветвления (Branching Strategies). Почему в неблокирующих СКВ появились и стали популярными сложные стратегии ветвления (например, Git Flow, GitHub Flow), в то время как в блокирующих СКВ они практически не применяются? Свяжите ваш ответ с принципами работы этих систем.

37. Проблемы производительности и их решение. С какими проблемами производительности может столкнуться команда при использовании централизованной СКВ (например, SVN) с очень большим репозиторием и числом файлов? Как распределённая СКВ (например, Git) частично решает эти проблемы за счёт своей архитектуры?

38. Роль СКВ за пределами хранения кода. Помимо хранения исходного кода, современные СКВ часто используются для ведения документации, управления конфигурациями инфраструктуры (IaC - Infrastructure as Code) и даже развертывания приложений. Какие свойства СКВ (например, ветвление, контроль изменений, тегирование) делают их пригодными для этих задач?

39. Анализ нишевых СКВ. Некоторые СКВ, такие как Darcs или Bazaar, не получили широкого распространения, как Git. Изучите их ключевые особенности (например, теория патчей в Darcs). Какие теоретические преимущества они предлагают и с какими практическими сложностями или недостатками производительности столкнулись, что ограничило их популярность?

40. Безопасность и аудит в СКВ. Какие механизмы предоставляют современные СКВ (в частности, Git) для обеспечения целостности и подлинности истории изменений? Почему классический централизованный сервер (как в SVN) представляет собой единую точку отказа не только для доступности, но и для безопасности данных, и как распределённость Git нивелирует этот риск?