Организация процесса разработки программных продуктов с использованием свободного ПО

Борис Турчик – IponWeb, Москва, Россия – bturchik@iponweb.net

LVEE 2007

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

основы организации разработки ПО

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

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

инструментарий разработчика

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

- платформа разработки;
- система контроля версий;
- система управления и распределения заданий;
- система автоматического тестирования;
- СУБД.

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

- PHP 5.x как основная платформа для разработки;
- Subversion в качестве системы контроля версий;
- RT в качестве управления заданиями;
- система автоматического тестирования была реализована самостоятельно на основе уже существовавшего кода функциональных тестов для смежного проекта. Для реализации использовался Perl;
- MySQL 5.x как СУБД.

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

Выбор операционной системы и редактора остался за разработчиком, при условии что оба продукта будут свободными. В результате чего на проекте используются Debian Sarge и Gentoo в качестве операционных систем (а так же CentOS на рабочих серверах), и Emacs/KDevelop/Eclipse в качестве редакторов.

соглашения по разработке

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

При написании кода использовались слегка модифицированные соглашения PEAR, т.к. основной код писался на PHP5, так же аналогичные правила применялись к написанию тестов. В общие правила входило так же требование написания тестов к любому изменяемому/дополняемому коду, т.е. никакая логика не должна была попасть в систему без тестов. Недостатком в данном случае являлось то, что код и тесты реализовывались одним и тем же разработчиком (за редкими исключениями). Однако этот недостаток восполнялся тем, что весь код отдавался на проверку старшим разработчикам, которые следили за тем, чтобы логика была надлежащим образом покрыта тестами. В случае если код был написан одним из старших разработчиков, он передавался на проверку другому. Следует также заметить, что в идеале тесты должны создаваться до того, как будет написана логика. К сожалению, такой стратегии сложно придерживаться, когда логика и тесты к ней создаются одним разработчиком.

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

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

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

Исходя из этого, структура выглядит следующим образом:

- тимлидер – осуществляет распределение частей проекта между старшими разработчиками, просмотр кода, отслеживает сроки выполнения заданий а так же создание новых при необходимости;

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

- младшие разработчики – осуществляют непосредственно разработку кода заданий, полученных от старших разработчиков.

этапы разработки

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

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

Базовые этапы разработки выглядят следующим образом:

- создаётся задание в соответствующей очереди RT;

- задание отдаётся на выполнение разработчику, присваивается в RT;

- разработчик, используя команды svn, копирует существующий код в отдельную ветку с номером задания;

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

- если в корневом репозитории произошли изменения, затрагивающие разработку, разработчик может синхронизировать свою ветвь с корневой;

- разработчик передаёт выполненное задание старшему, переназначая его в RT;

- старший разработчик соединяет код ветви с корневым кодом, просматривает разницу кода, тестов, а так же запускает тесты;

- при наличии конфликтов или недочётов в коде задание отдаётся обратно разработчику;

- если старший разработчик подтверждает изменения, он помещает их в корневой svn и, при необходимости, в предыдущие версии;

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