Лекция 4

1. Методы организации работы в команде разработчиков. Системы контроля версий

2. Модели коллективов разработчиков

Разработки программы в зависимости от
количества участников и типов
взаимоотношений между участниками
делятся на виды:
• Авторская разработка
• Коллективная разработка
• Общинная модель разработки

3. Авторская разработка

Авторская разработка – это создание программных продуктов, при котором весь
жизненный цикл разработки поддерживается одним человеком. Был распространён
в г.г. и сейчас применяется редко из-за сложности, объема, требуемого качества,
сопровождения.
С появлением ПК программное обеспечение стало продуктом массового
применения, поэтому стали доминировать крупные компьютерные компании с
развитой структурой менеджмента и рекламной компанией. Авторские разработки
применяются в области наукоемких приложений и при создании условно бесплатных
программных продуктов. Для таких приложений характерна необходимость
многолетнего изучения предметной области, практически полное отсутствие
начального финансирования проекта, малая рентабельность, которая определяется
узким кругом области.

4. Коллективная разработка

Коллективная разработка – это создание программного продукта коллективом
разработчиков. Один из основных вопросов коллективной разработки является
разделение труда. Один человек не способен создать приложение масштаба
предприятия. Ни один разработчик просто не удержит в голове все требования к
системе и варианты проекта. Поэтому сегодня разработкой промышленных систем
занимаются проектные группы, и все обязанности распределяются среди членов
группы.
Существует две основные модели организации коллектива при разработке ПО:
1) иерархическая модель
2) Специализированная модель
3) Гибкая (Agile)

5. Иерархическая модель

Характеризуется чётким разделением фаз и обязанностей.
Некоторые особенности:
1. Сотрудники на разных уровнях придерживаются древовидной структуры.
2. Сотрудники нижнего уровня, как правило, обладают наиболее подробными
знаниями о системе, сотрудники более высоких уровней — более широким
представлением о проекте в целом.
3. Информация идёт в одном направлении — вверх по иерархии, к главному
менеджеру.
Недостатки:
нехватка информации;
невозможность учесть все особенности проекта;
затруднённый обмен информацией — он осуществляется через посредников.

6. Специализированная модель

Формируется в зависимости от конкретных задач и технологий, необходимых для
реализации проекта. В состав входят эксперты в определённых областях, например, UXдизайн, разработка баз данных или создание мобильных приложений.
Преимущества:
у участников команды высокая квалификация и опыт в своей области;
специализированные команды быстрее справляются с задачами благодаря
сосредоточенности на конкретных аспектах проекта;
эксперты в своей области предлагают новые идеи и решения, что способствует
инновационному подходу к разработке.
Недостатки:
специализация иногда ведёт к недостатку общего видения проекта и целей;
у разных специалистов бывают разные подходы и язык, что усложняет взаимодействие.

7. Гибкая (Agile)

Предполагает работу короткими циклами — итерациями длиной в две-три недели. Каждая
итерация включает полный цикл разработки: анализ, проектирование, кодирование,
тестирование, выкладку рабочей версии продукта. После завершения итерации команда
анализирует результаты и применяет выводы в следующем цикле.
Особенность: отказ от жёсткой иерархии — здесь нет традиционных начальников, есть роли,
которые участники берут на себя для достижения общей цели.
Product Owner (Владелец продукта) — формулирует видение продукта, управляет бэклогом
задач и расставляет приоритеты.
Scrum Master/Agile Coach — помогает команде следовать выбранному процессу, устраняет
препятствия и фасилитирует встречи, чтобы каждый понял позицию другого.
Разработчики — те, кто непосредственно создаёт продукт. Это могут быть backend, frontend,
mobile-разработчики, DevOps-инженеры — в зависимости от специфики проекта.

8. Преимущества и недостатки

Преимущества:
гибкость и адаптивность — можно оперативно менять приоритеты, добавлять новые фичи и
реагировать на изменения рынка без перезапуска всего проекта;
снижение рисков — регулярное тестирование и обратная связь позволяют выявлять проблемы
на ранних стадиях;
гибкие дедлайны — сроки планируются с учётом возможных изменений и задержек, что
снижает стресс команды.
Недостатки:
непредсказуемость результата — финальный продукт может существенно отличаться от
первоначальной задумки;
требовательность к коммуникации — постоянное взаимодействие с заказчиком обязательно;
сложный онбординг — ввести нового человека в проект непросто — требуется время на
погружение в контекст и командные практики.
Многие команды используют гибридные подходы, комбинируя практики из разных фреймворков
под свои задачи

9.

VCS
Система управления версиями (от англ. Version Control System, VCS или Revision Control
System) — программное обеспечение для облегчения работы с изменяющейся
информацией. Система управления версиями позволяет хранить несколько версий
одного и того же документа, при необходимости возвращаться к более ранним
версиям, определять, кто и когда сделал то или иное изменение, и многое другое

10.

Назначение VCS
Архивация и восстановления
Синхронизация работы с командой
Поиск “виновного”
Хранения истории разработки
Отмена изменений
Альтернативные/экспериментальные реализации

11.

Классификация систем контроля версий
Централизованные/распределённые
— в централизованных системах
контроля версий вся работа производится с центральным репозиторием, в
распределённых — у каждого разработчика есть локальная копия
репозитория.
Блокирующие/не блокирующие — блокирующие системы контроля
версий позволяют наложить запрет на изменение файла, пока один из
разработчиков работает над ним, в неблокирующих один файл может
одновременно изменяться несколькими разработчиками.
Для текстовых данных/для бинарных данных — для VCS для текстовых
данных очень важна поддержка слияния изменений, для VCS с бинарными
данными важна возможность блокировки.

12.

GIT
Git — распределённая система управления версиями файлов. Позволяет
отслеживать и записывать любые изменения в наборе файлов, возвращаться к
предыдущим версиям проекта. Проект был создан Линусом Торвальдсом для
управления разработкой ядра Linux в 2005 году.
Плюсы:
Высокая производительность.
Развитые средства интеграции с другими VCS.
Репозитории
git могут распространяться и обновляться общесистемными
файловыми утилитами, такими как rsync.

13.

14.

Схема работы с Git
В отличие от многих других систем контроля версий, которые отслеживают изменения файлов
как наборы различий (дельт), Git сохраняет снимки состояния всего проекта в каждый момент
времени. Каждый раз, когда создаётся коммит, Git делает снимок всех файлов в проекте и
сохраняет ссылку на этот снимок. Если файлы не изменились с момента предыдущего коммита,
Git не дублирует их, а просто создаёт ссылку на уже сохранённую версию.
Некоторые команды для работы с Git:
git pull/ fetch — забираем изменения из центрального репозитория
git push — вносим изменения в удаленный репозиторий
git commit — совершение коммита
git checkout — переключение между ветками, извлечение файлов
git merge — слияние веток (разрешение возможных конфликтов)
git add — позволяет внести в индекс— изменения, которые затем войдут в коммит

15.

Структура Git
Репозиторий Git — это специальная база данных, которая хранит не только все файлы
проекта, но и полную историю их изменений, а также всю служебную информацию,
необходимую для работы. Физически репозиторий представляет собой скрытую папку
.git в корне проекта.
Существует два основных типа репозиториев:
Локальный — полноценная копия репозитория, расположенная на компьютере. С
ней работают напрямую (совершают коммиты, просматривают историю, создают
ветки и т. п.).
Удалённый — версия проекта, размещённая на сервере (например, на GitLab или
внутреннем корпоративном сервере). Используется для обмена изменениями между
разработчиками и для резервного копирования кода.

16.

Вопросы
Какие есть виды разработки программы в зависимости от количества участников и
типов взаимоотношений между участниками?
Какие существуют основные модели организации коллектива при разработке ПО?
Для чего нужна система управления версиями?
Какие существуют классификации систем контроля версий?