Эд Салливан - Время — деньги. Создание команды разработчиков программного обеспечения

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

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

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

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

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

И последнее (но не менее ценное) преимущество — централизация файлов в системе управления исходным кодом обеспечивает простое резервное копирование всего проекта. Одной командой мы могли создать резервную копню или просто скопировать весь проект на другой диск или другую машину.

Помимо функциональных возможностей, описанных ранее, команда в NuMega нуждалась в поддержке пяти жизненно необходимых технологических возможностей. Хотя они специфичны для наших продуктов и компании, многие из них стандартны для большинства проектов в отрасли. Это:

• управление разработкой нескольких редакций продукта;

• управление разработкой нескольких версий одной редакции;

• применение общих компонентов, как в рамках одного, так и нескольких проектов компании;

• компоновка продукта на основе самого свежего набора файлов с исходным кодом (или на основе другого набора исходных файлов);

• поддержка локальных сборок для отдельных разработчиков.

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

Мы использовали систему управления исходным кодом Visual Source Safe (VSS) компании Microsoft. Она предоставляет нужные нам основные функции, и у неё отличная цена — как раз для начинающего бизнеса. Хотя обсуждение VSS выходит за рамки этой книги, я расскажу о том, как мы приспособили этот продукт под наши нужды.

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