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

Автор книги: Эд Салливан

сообщить о нарушении

Текущая страница: 6 (всего у книги 19 страниц)

Корпоративная культура

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

Почему культура так важна?

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

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

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

Как воспитать корпоративную культуру?

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

Из собственного опыта

Воспитывая корпоративную культуру NuMega, мы специально предпринимаем ряд конкретных действий.

• Чётко определяем, кто мы и какие цели преследуем

Нам совершенно ясно, кто мы и что должны делать. Звучит довольно просто, да? Но на деле это не так просто, как кажется.

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

• Культивируем элитарность

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

• Отмечаем успехи и помним свою историю

Со временем в компании сформировалась история выпуска замечательных продуктов, успешных как в техническом, так и в экономическом отношении. «Отцы-основатели» постоянно приводят эти успехи в качестве примеров на собраниях и неформальных встречах. Все следят за тем, чтобы каждый новичок знал историю и путь развития компании. Это стимулирует формирование культуры стремления к успеху, создания замечательных продуктов и заставляет быть экспертом в выбранной нами области.

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

• Поддерживаем дух соперничества

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

• У нас свои способы отдохнуть и весело провести время

У работников технических компаний есть два удовольствия: возможность от души повеселиться и разные способы отдохнуть от повседневных забот. У нас куча всяких вещиц: футболок, рекламных материалов с выставок, бесплатных обедов, кроме того, «NuMega specials» (пицца с поджаренным луком, чесноком и жгучим «чили»), самодельные площадки для гольфа и велосипедные дорожки прямо в помещениях компании. Всё это формирует атмосферу исключительности и веселья. Мы знаем, что это очень нетипично, но это нам и нравится!

• Не прячем своих разработчиков от клиентов

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

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

***

Немного конкретизируем изложенное выше. Первый этап формирования культуры – определение приоритетных ценностей. Какие ценности заложены в культуре вашей компании в данный момент? Какие ценности должны быть воплощены в будущем? Подумайте, можно ли сказать, что ваша команда:

• ценит выполненную вовремя работу?

• ценит техническое превосходство?

• ценит высокое качество?

• ценит даже минимальный вклад?

• поощряет риск?

• поощряет исключительную производительность труда?

• проявляет благородство?

• небезразлична к социальным проблемам?

• считает, что каждый должен принимать участие в тестировании продукта?

• оперативно реагирует на внешние угрозы?

• считает, что тестирование практичности программы имеет решающее значение?

• считает сверхурочную работу обычным делом при отставании от графика?

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

Корпоративная культура и технологические приёмы

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

Вот некоторые правила, которых полезно придерживаться при росте организации:

• Взвешивайте затраты на внедрение технологических приёмов и пользу от них

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

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

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

• Прежде, чем внедрять новые приёмы, нужно извлечь максимум из имеющихся

Один из самых обескураживающих аспектов разработки ПО – внедрение новых приёмов, в то время как команда не полностью использует все возможности имеющихся. В вашей команде так быть не должно. За правильное использование имеющихся приёмов отвечают менеджеры и ведущие специалисты. Можно потерять доверие участников команды, санкционируя добавление новых технологических приёмов и игнорируя те, что уже есть. Если обнаружится, что ни один из имеющихся документированных приёмов не используется полностью, созовите собрание группы и решите, представляют ли они ценность. Да – оставьте их и используйте «на все сто». Нет – избавьтесь от лишних технологических приёмов. Что толку держать приёмы, развесив их по стенам, как картины? Они только портят интерьер.

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

• Взвешивайте потребности отдельного специалиста и всей команды

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

Из собственного опыта

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

Представляет ли новый приём ценность для компании? Иногда – да, когда дополнительная точная информация позволит легче устранять ошибки, но число таких ошибок не превышает 5-10 в месяц. Однако затраты на ввод этой информации, который должны были выполнять 15 человек на протяжении всего внутреннего цикла разработки (особенно когда приходилось регистрировать до 10 ошибок в день), не стоили потенциальной пользы. Кроме того, большинство ошибок воспроизводилось на любой машине, в противном случае было нетрудно связаться с офисом, откуда поступило сообщение об ошибке, и выяснить необходимую информацию о конфигурации.

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

Типичные проблемы и их решение

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

Проблемы с ранжированием

• Не держите ранжирование в секрете

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

• Не затрудняйте переход из одного круга в другой

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

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

• Не заводите фаворитов

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

• Играйте честно

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

Проблемы с культурой

• Культуру можно изменить

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

• Если организация растёт

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

– кто мы?

– чем мы занимаемся?

– почему мы делаем своё дело лучше, чем кто-либо другой?

– чем мы отличаемся от других?

– что мы ценим?

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

Глава 5
Инструментальные программы

В компании NuMega мы использовали лишь те инструментальные программные средства, которые были жизненно необходимы для нашей работы и вписывались в наш стиль работы. Из всех доступных инструментов мы больше всего применяли и полагались на систему управления исходным кодом и систему устранения проблем и неисправностей (поиска «жучков»). Возможность приспосабливать эти продукты к нашим нуждам позволила ускорить работу – вся команда использовала их почти каждый день.

Средства управления исходным кодом

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

О чём пойдёт речь

Продукты по управлению исходным кодом хранят файлы с кодом, отслеживают их версии, управляют файлами, составляющими проект, и предоставляют следующие функции.

• Хранение файла и его прошлых, настоящих и будущих версий

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

• Отслеживание истории изменений для каждого файла

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

• Группирование файлов

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

• Маркировка файлов, связанных с конкретным выпуском программного продукта

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

• Блокировка и разблокировка файлов

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

Что туда входит

Удобное расположение всех файлов и информации, связанной с проектом – это страшная (но излечимая) головная боль при разработке ПО. В NuMega не было времени создавать обширную инфраструктуру или сложные процессы для поддержки грамотного документооборота. Поэтому мы решили просто поместить все файлы и документы проекта в систему управления исходным кодом. Это были:

• исходные файлы;

• файлы заголовков;

• файлы библиотек;

• сценарии компоновки;

• результаты компиляции;

• результаты компоновки;

• инструменты и файлы для установки программ;

• инструменты и файлы для тестирования;

• спецификации проекта;

• планы проекта (ПО, документации и тестирования);

• пользовательская документация;

• тестовые задания и сценарии;

• тестовые модули разработчиков.

Из собственного опыта

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

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

Зачем это нужно

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

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

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

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

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

Каковы их технологические возможности

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

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

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

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

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

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

Как ими управлять

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

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

Основы структуры

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

Структура и использование хранилища исходного кода

Все файлы, используемые при разработке наших продуктов, были рассортированы по трём папкам:

• Product Name – для файлов, относящихся к продукту;

• Environment – для файлов среды разработки;

• Imports – для сторонних файлов.

Папка Product Name содержала создаваемые нами файлы, необходимые для сборки, тестирования и написания документации к продукту (табл. 5-1). В ней были подкаталоги Branch для каждого варианта, над которым мы работали. В подкаталоге Parts хранились стандартные и совместно используемые компоненты, включаемые в продукт. И, наконец, для каждой редакции продукта имелся подкаталог Product. В каждой папке Product содержались необходимые для продукта части. Чтобы эта структура работала, нужно строго соблюдать соглашения об именах и не нарушать структуру. Координация изменений в частях и продуктах также была критичной.

Табл. 5-1. Примерная структура папки «Product Name».

$/Product_Name/ – Файлы, относящиеся к продукту

$/Product_Name/Branch/ – Различные направления в разработке

$/Product_Name/Parts/ – Совместно используемые файлы, входящие в продукт

$/Product_Name/Parts/Src/ – Исходный код для Parts (при необходимости совместно используется с/Products/Src)

$/Product_Name/Parts/Doc/ – Исходные файлы документации

$/Product_Name/Parts/Help/ – Исходные файлы справочной системы

$/Product_Name/Parts/Install/ – Исходный код программы установки

$/Product_Name/Parts/Patch/ – Исходный код вставок

$/Product_Name/Parts/Setup/ – Исходный код установщика

$/Product_Name/Parts/Samples/ – Исходный код с примерами

$/Product_Name/Parts/Tests/ – Исходный код тестов, тестовые задания и т.д.

$/Product_Name/Product/ – Редакции продукта Product Name (по одной папке на каждую редакцию)

$/Product_Name/Product/Output/ – Область для программ, созданных в других проектах

$/Product_Name/Product/Src/ – Исходный код продукта (при необходимости совместно используется с /Parts/Src)

$/Product_Name/Product/Doc/ – Файлы документации к продукту (совместно используется с /Parts/Doc)

$/Product_Name/Product/Help/ – Файлы справочной системы продукта (совместно используется с /Parts/Help)

$/Product_Name/Product/Imports/ – Импорт (совместно используется с /Imports)

$/Product_Name/Product/Install/ – Файлы для установки продукта (используется с /Parts/Install)

$/Product_Name/Product/Samples/ – Примеры для продукта (совместно используется с /Parts/Samples)

$/Product_Name/Product/Tests/ – Тестовые задания, тестовые сценарии (совместно используется с /Parts/Tests)

Из собственного опыта

Когда я пришёл в NuMega, для одного из продуктов было создано три каталога по именам разработчиков: Frank, Bill и Matt. Так как каждый работал над своим собственным кодом, они могли вносить изменения, не повреждая чужих файлов. Однако там было мало общего кода (одна большая структура данных для основных подсистем). Но это работало! Дальше нам нужно было увеличить команду разработчиков, и мы уже не могли обойтись без системы управления исходным кодом. Такая система позволила усложнить проект, удерживая его под контролем. Без неё я просто не могу представить ПО для разработчиков.

В папке Environment ($/Env) хранятся файлы, используемые командой разработчиков, но не являющиеся частью конечного продукта. Это все, начиная с инструментов и утилит и заканчивая стандартами создания кода и шаблонами для проекта. Папка Environment содержит файлы среды, описывающие среду с точки зрения разработчика, а также с точки зрения тестирования и документации. В NuMega мы хотели создать общую среду для команд разработчиков, и потому для этой цели мы создали специальный раздел в хранилище исходного кода. Вот примерный список подкаталогов, которые могут быть в этом разделе хранилища исходного кода (табл. 5-2):

Табл. 5-2. Примерная структура папки Environment.

$/Env/Dev/ ПО среды разработки и инструментальных средств

$/Env/Dev/Bin Исполняемые модули (подкаталог для каждого инструмента)