СПОСОБЫ  ОРГАНИЗАЦИИ  КОМАНДНОЙ  РАБОТЫ  НАД  ПРОЕКТАМИ

Караваев  Вадим  Юрьевич

студент  4  курса  кафедры  «Автоматизированных  систем  управления»  Московского  государственного  университета  приборостроения  и  информатики,  филиал,  РФ,  г.  Ставрополь

E -mail:  5665tm@gmail.com

Авакян  Тамара  Ашотовна

научный  руководитель,  доцент  кафедры  «Автоматизированных  систем  управления»  Московского  государственного  университета  приборостроения  и  информатики,  филиал,  РФ,  г.  Ставрополь

При  работе  над  достаточно  крупными  проектами  с  участием  нескольких  человек,  неизбежно  встает  вопрос  об  организации  эффективного  рабочего  процесса.  Стоит  сказать  о  некоторых  характеристиках  проекта,  о  котором  упоминается  в  статье:  тип  —  онлайн  игра,  два  модуля  —  клиентская  часть  на  Unity  Engine,  и  серверная  часть  на  NET.  Framework  4.5,  в  общей  сложности  20  тысяч  строк  кода  на  C#,  несколько  сотен  графических  файлов  в  различных  форматах,  несколько  десятков  звуковых  файлов  и  большое  количество  других  типов  данных.

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

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

2.  Использование  систем  контроля  версий.  Это  специальное  программное  обеспечение  для  управления  изменяющейся  информацией  и  незаменимое  средство  для  командной  разработки.  Системы  контроля  версий  выполняют  большое  количество  функций.  Рассмотрим  их  подробнее.

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

Рисунок  1.  Список  коммитов  проекта

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

·     Простое  и  быстрое  резервное  сохранение  данных  на  сервере.  И  снова,  за  счет  того  что  на  сервер  передается  только  дельта,  а  это  сравнительно  небольшое  количество  информации  по  сравнению  с  общим  объемом  проекта,  возникает  выигрыш  в  количестве  передаваемых  данных,  и  как  следствие  времени  на  такие  передачи.

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

Примеры  систем  контроля  версий  —  Git,  Team  Foundation  Server,  Mercury,  SVN.  На  сегодняшний  момент  самой  распространенной  является  Git  (Рисунок  2).  Проект  был  начат  Линусом  Торвальдсом,  и  изначально  предназначался  для  управления  разработкой  ядра  Linux,  где  и  зарекомендовал  себя  надежной  системой  отлично  подходящей  для  контроля  разработки  даже  самых  крупных  проектов  [3,  с.  123].

Рисунок  2.  Консоль  управления  Git

3.  Использование  веб-сервиса  для  хостинга  проектов.  Примеры  таких  веб-сервисов  —  Github,  Bitbucket.  Типичный  веб-сервис  имеет  в  своем  распоряжении  большое  количество  полезных  инструментов:  возможность  удаленно  хранить  репозитории  систем  контроля  версий,  багтрекер,  трекер  задач,  вики-страницы.

Хранение  удаленных  репозиториев,  решает  проблему  с  хранением  и  резервированием  исходных  данных.  Даже  если  проект  хранился  в  единственном  экземпляре  у  одного  из  разработчиков  и  был  вследствие  непредвиденных  обстоятельств  утерян,  копия  этого  проекта  всегда  будет  находиться  на  удаленном  сервере.  Также  можно  организовать  хранение  репозиториев  на  локальном  сервере  при  помощи  соответствующих  программных  средств.  Например,  если  сервер  находится  под  управлением  ОС  семейства  Windows,  хорошим  выбором  является  Bonobo  Git  Server.

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

Трекер  задач  —  система  для  отслеживания  задач  возникающих  в  проекте  (Рисунок  3).  В  трекере  можно  создавать  записи,  включающая  в  себя  следующую  информацию  о  задачах  -  название,  описание,  кто  создал  задачу,  кому  адресовано  ее  выполнение,  тип,  приоритет  задачи  (trivial,  minor,  major,  critical,  blocker).  Обычно  задачи  могут  предлагаться  всеми  участниками  проекта,  однако  утверждать  их  к  обязательному  исполнению  вправе  только  руководитель.  Задачи  с  наибольшим  приоритетом  должны  выполняться  в  первую  очередь.  Довольно  часто  трекер  задач  так  же  совмещает  в  себе  функции  багтрекера,  в  таком  случае  задаче  присваивает  тип  bug.  Задачи  типа  bug  с  приоритетом  critical  и  выше,  обычно  решаются  без  утверждения  руководителя.

Рисунок  3.  Список  задач  на  Bitbucket

Если  было  решено  использовать  не  веб-хостинг,  а  хранение  репозиториев  на  локальном  сервере,  либо  требуется  более  мощный  трекер  задач,  чем  тот  который  предлагается  веб-хостингом,  можно  использовать  отдельные  программные  модули,  такие  как  JIRA,  Redmine,  Asana.

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

4.  Документация  по  коду.  Даже  если  в  команде  всего  один  программист,  код  обязательным  образом  должен  быть  хорошо  прокомментирован.  Однако  комментариев  не  должно  быть  слишком  много,  это  тормозит  рабочий  процесс,  и,  как  это  не  парадоксально,  часто  даже  затрудняет  чтение  кода.  Общее  правило  таково  -  один  комментарий  на  блок  из  нескольких  строк  кода  выполняющих  определенную  функцию.  Число  таких  строк  от  5до  20.  Для  комментирования  методов  и  типов,  в  языке  C#  имеется  механизм  XML-комментирования.  При  компиляции  проекта  все  комментарии  выполненные  таким  образом  собираются  в  отдельный  XML-файл,  а  в  IDE  такой  файл  будет  использован  для  средств  Intellisense  [1,  с.  278].  Также  на  основе  этого  XML-файла  в  последующем  можно  будет  сгенерировать  отдельный  файл  документации  при  помощи  сторонних  программных  средств,  например  Sandcastle.  Сгенерированная  документация  может  быть  в  форматах  DOC,  PDF,  CHM,  Html  страниц.

5.  Грамотная  структура  проекта.  Исходники  проекта  должны  быть  грамотно  структурированы.  Общепринятым  стандартом  для  проектов  на  Unity  является  следующая  структура  папок:  Textures  —  для  файлов  текстур,  Scripts  —  для  файлов  исходных  кодов,  Interface  —  для  графических  файлов  интерфейса,  Models  —  для  3D  моделей,  Sprites  —  для  2D  спрайтов,  Sounds  —  для  звуков  в  игре,  Music  —  для  саундтрека,  Extras  —  для  подключаемых  плагинов  и  остальных  типов  данных  [2].  Все  файлы  проекта  должны  иметь  английские  названия,  так  как  английский  язык  давно  стал  стандартом  де-факто  в  среде  разработчиков.  Такой  подход  позволяет  свободно  ориентироваться  в  проекте  носителю  любого  языка,  и  на  корню  решает  все  проблемы  с  кодировкой  при  использовании  любых  инструментальных  средств. 

Список  литературы:

1.Рихтер  Д.  CLR  via  C#.  Программирование  на  платформе  Microsoft  .NET  Framework  4.5  на  языке  C#.  4-е  изд.  СПб.:  Питер,  2015.  —  896  с.:  ил.

2.Руководство  Unity  //  Официальный  сайт  Unity  Engine  [Электронный  ресурс]  —  Режим  доступа.  —  URL:  http://docs.unity3d.com/ru/current/Manual/UnityManualRestructured.html  (дата  обращения  03.03.2015).

3.Чакон  С.  Pro  Git.  2-е  изд.  New  York.:  Apress,  2014.  —  456  с.