Лекция №4

1.

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

2.

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

3.

Авторская разработка
Авторская разработка – это создание ПО
одним человеком, охватывающее весь его
жизненный цикл, включая планирование,
разработку, тестирование, развертывание и
сопровождение. Такая модель была более
распространена в 60-х и 70-х годах XX века
и сейчас применяется редко из-за высокой
сложности, больших объемов работ,
требований к качеству и необходимости
сопровождения, которые трудно обеспечить
одному человеку.
С развитием ПК программное обеспечение
превратилось в массовый продукт, что
привело к доминированию крупных
компаний с развитым менеджментом и
маркетингом. Авторские разработки нашли
свою нишу в наукоемких приложениях и
условно-бесплатных (freemium) продуктах,
которые требуют глубокого изучения
предметной области, имеют низкое
начальное финансирование и малую
рентабельность из-за ограниченного рынка.

4.

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

5.

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

6.

Основные этапы разработки
программного обеспечения
Основные этапы разработки программного обеспечения
включают:
Сбор и анализ требований
Планирование
Проектирование
Разработка (кодирование)
Тестирование,
Развертывание (внедрение) и Обслуживание (поддержка).
Эти этапы составляют жизненный цикл разработки
программного обеспечения (SDLC) и помогают пройти путь от
идеи до готового продукта.

7.

Система контроля версий
Система контроля версий (СКВ, VCS) — это программное обеспечение для
отслеживания и управления изменениями в файлах проекта, позволяющее сохранять
историю всех изменений, возвращаться к предыдущим версиям, совместно работать
над проектом и безопасно экспериментировать с кодом. По сути, это как Google
Документы, но для кода и других изменяющихся файлов, предотвращающее потерю
информации и конфликты при параллельной работе нескольких человек.

8.

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

9.

Система контроля версий
Локальные системы контроля версий — простые системы, где вся история изменений
хранится на компьютере разработчика. Все изменения фиксируются в локальном репозитории,
и каждый пользователь работает с собственной копией данных. Для обмена файлами с
другими разработчиками нужно вручную копировать их.
Централизованные системы контроля версий хранят всю историю изменений и актуальные
версии проекта на одном сервере. Разработчики работают с локальными копиями исходного
кода и для получения последних изменений или отправки своих правок подключаются к
серверу. Центральный репозиторий является единственным источником правды.
Распределённые системы контроля версий — более продвинутый и гибкий подход.
Распределённые системы контроля версий, такие как Git, позволяют каждому разработчику
иметь полную локальную копию репозитория с историей изменений. Можно работать без
постоянного доступа к серверу и синхронизировать изменения с другими участниками по мере
необходимости. Git, используемый в таких сервисах, как GitHub и GitLab, — яркий пример
распределённой СКВ.

10.

Принципы работы системы контроля версий
Репозиторий
Репозиторий — это централизованное
хранилище всего процесса. Как правило,
репозиторий находится на удаленном сервере
в облачном хранилище.
Чтобы начать работу с проектом, необходимо
скачать полную копию репозитория на свой
компьютер. Такая копия называется
локальным репозиторием.
СКВ обменивается изменениями между
этими репозиториями. Так все изменения,
внесенные в облачный репозиторий, могут
быть загружены в локальный, и наоборот.
Коммит
СКВ помогает сохранять так называемые
«снимки» состояния проекта, его
промежуточные версии. Это своего рода
опорные точки, к которым разработчик
может вернуться в случае необходимости.
Такие сохранения называются коммитами.
Коммиты содержат информацию о том, какие
изменения были внесены в исходный код, но
не весь проект целиком. Таким образом
система контроля версий может сохранять
большое количество изменений с
минимальными затратами на ресурсы.

11.

Принципы работы системы контроля версий
Ветка
Ветка — это специальная, созданная
параллельно с основным репозиторием,
копия проекта. Ветвление позволяет
изолировать изменения, экспериментировать
с новыми функциями и исправлять ошибки,
не влияя на стабильность основной базы
кода — master-ветку