Frank, Bill и Matt. Так как каждый работал над своим собственным кодом, они могли вносить изменения, не повреждая чужих файлов. Однако там было мало общего кода (одна большая структура данных для основных подсистем). Но это работало! Дальше нам нужно было увеличить команду разработчиков, и мы уже не могли обойтись без системы управления исходным кодом. Такая система позволила усложнить проект, удерживая его под контролем. Без неё я просто не могу представить ПО для разработчиков.
В папке Environment ($/Env) хранятся файлы, используемые командой разработчиков, но не являющиеся частью конечного продукта. Это все, начиная с инструментов и утилит и заканчивая стандартами создания кода и шаблонами для проекта. Папка Environment содержит файлы среды, описывающие среду с точки зрения разработчика, а также с точки зрения тестирования и документации. В NuMega мы хотели создать общую среду для команд разработчиков, и потому для этой цели мы создали специальный раздел в хранилище исходного кода. Вот примерный список подкаталогов, которые могут быть в этом разделе хранилища исходного кода (табл. 5-2):
Табл. 5-2. Примерная структура папки Environment.
$/Env/Dev/ ПО среды разработки и инструментальных средств
$/Env/Dev/Bin Исполняемые модули (подкаталог для каждого инструмента)
$/Env/Dev/Src Исходный код для этих инструментов (подкаталог для каждого)
$/Env/Dev/Doc Документация для этих инструментов (подкаталог для каждого)
$/Env/Dev/Etc Прочие файлы
$/Env/Test/ Инструментальные средства и файлы для тестирования
$/Env/Test/Bin Исполняемые модули
$/Env/Test/Src Исходный код и документация для этих инструментов
$/Env/Test/Doc Документация по среде тестирования
$/Env/Test/Etc Прочие файлы
$/Env/Documentation/ Документация по среде проекта
$/Env/Documentation/Templates Шаблоны проекта, шаблоны документации и справочники по стилям
$/Env/Documentation/Plans Планы и спецификации проекта, тестовых заданий и документации
$/Env/Documentation/Process Технологические документы проекта
$/Env/Etc Прочие файлы, не вошедшие в предыдущие категории
В папке Imports ($/Imports) хранились файлы или наборы инструментов из сторонних продуктов (табл. 5-3). Сами сторонние продукты в этой папке не содержались, там были только библиотеки и заголовки. В результате в разделе Imports проводилось совсем немного изменений. Однако так как эта область использовалась для хранения различных версий сторонних продуктов, было очень важно не вносить никаких изменений без чёткого осмысления, полного тестирования и учёта связей с элементами, на которые эти изменения могли бы подействовать.
Табл. 5-3. Примерная структура папки Imports.
$/Imports/RogueWave Библиотеки и заголовки RogueWave
$/Imports/ObjectSpace Библиотеки и заголовки ObjectSpace
$/Imports/Visual С Результаты компиляции, библиотеки и заголовки Visual С
$/Imports/Install Shield Библиотеки и заголовки Install Shield
$/Imports/Прочие Папки для каждого инструмента или библиотеки сторонних производителей
Компоновочная система
В NuMega мы писали сценарий сборки продукта на выделенной «компоновочной машине». Сценарий должен был выбирать нужные для сборки продукта файлы из системы управления исходным кодом. Эта информация включала как сами средства компоновки, так и исходные файлы, библиотеки, заголовки и другие необходимые компоненты. Для ведения процесса компиляции мы выбрали Nmake — популярное средство управления компоновкой. Nmake сначала собирает все части продукта, а затей компонует окончательные исполняемые файлы продукта.
Сценарий компоновки в качестве входных данных принимал метку сборки, позволяло нам создать определённые версии продукта. Так как мы маркировали и отбирали и средства сборки, и файлы продукта, то таким образом мы гарантировали надёжность сборочной среды. Сценарии компоновки также использовали стандартные переменные окружения и макросы, так что мы собирали все части и продукты посредством одного вызова. То, что наша компоновочная машина и разработчики использовали одни и те же сценарии компоновки, позволяло собирать файлы проекта просто и без ошибок.
Надёжная автоматическая система компоновки — необходимое условие успешной разработки. Затраты времени и сил на то, чтобы заставить эту систему работать, своего стоят. Этот и другие вопросы применения технологического ПО обсуждаются в главе 7.
Устранение проблем и неисправностей
Разработка ПО — это динамичный процесс с интенсивным обменом информацией между его участниками. При работе команды над проектом очень важно определить формальные методы поиска и устранения проблем, неисправностей и «жучков», которые постоянно появляются. Применение специальных продуктов для устранения проблем и неисправностей — один из лучших выходов. В оставшейся части главы объясняется, как эффективно использовать такие продукты.
О чём пойдёт речь
ПО для устранения проблем и неисправностей позволяет справляться с бесконечными ошибками и проблемами, всплывающими на поверхность в процессе разработки. Эти программы позволяют членам команды протоколировать, обновлять, назначать, устанавливать приоритет, сортировать и пересматривать информацию, полученную в цикле разработки проекта. Они являются важной частью любого проекта независимо от его размера. Никто не в состоянии запомнить все ошибки и проблемы, которые следует разрешить. И если они не протоколируются, не пересматриваются и для них не устанавливается приоритет, качественного продукта не создать.
Что туда входит
В NuMega использовали систему устранения проблем и неисправностей для хранения любых постоянных или временных данных о проекте, которые только можно было представить. Туда входили все программные ошибки (в том числе функциональные, затрагивающие производительность, процесс установки и параметры, а также все ошибки при сборке) и решения или предложения по улучшению проекта, его настоящих и будущих версий. Здесь действует простой, но очень важный принцип: все данные должны храниться в одном месте. Не следует держать их в хранилище, не обеспечивающем совместное использование, резервное копирование и простой доступ. (Поэтому сообщения электронной почты не подходят!)
Примечание
Я бы не советовал писать собственные программы по устранению проблем и неисправностей, так как хватает различных коммерческих программных продуктов по разумным ценам. Например, Compuware/NuMega TrackRecord, PVCS Tracker, Rational ClearQuest и др. Хотя вам потребуется самим определить, какая из них отвечает вашим потребностям, я настоятельно рекомендую принять решение в пользу покупки. Ведь вы не обязаны тратить время на создание собственных инструментов, ваше дело — поставлять ПО.
Рассмотрим пример. Разработчик замечает, что производительность в одной из частей приложения здорово снизилась, и сообщает об этом по электронной почте в конференцию разработчиков.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73
В папке Environment ($/Env) хранятся файлы, используемые командой разработчиков, но не являющиеся частью конечного продукта. Это все, начиная с инструментов и утилит и заканчивая стандартами создания кода и шаблонами для проекта. Папка Environment содержит файлы среды, описывающие среду с точки зрения разработчика, а также с точки зрения тестирования и документации. В NuMega мы хотели создать общую среду для команд разработчиков, и потому для этой цели мы создали специальный раздел в хранилище исходного кода. Вот примерный список подкаталогов, которые могут быть в этом разделе хранилища исходного кода (табл. 5-2):
Табл. 5-2. Примерная структура папки Environment.
$/Env/Dev/ ПО среды разработки и инструментальных средств
$/Env/Dev/Bin Исполняемые модули (подкаталог для каждого инструмента)
$/Env/Dev/Src Исходный код для этих инструментов (подкаталог для каждого)
$/Env/Dev/Doc Документация для этих инструментов (подкаталог для каждого)
$/Env/Dev/Etc Прочие файлы
$/Env/Test/ Инструментальные средства и файлы для тестирования
$/Env/Test/Bin Исполняемые модули
$/Env/Test/Src Исходный код и документация для этих инструментов
$/Env/Test/Doc Документация по среде тестирования
$/Env/Test/Etc Прочие файлы
$/Env/Documentation/ Документация по среде проекта
$/Env/Documentation/Templates Шаблоны проекта, шаблоны документации и справочники по стилям
$/Env/Documentation/Plans Планы и спецификации проекта, тестовых заданий и документации
$/Env/Documentation/Process Технологические документы проекта
$/Env/Etc Прочие файлы, не вошедшие в предыдущие категории
В папке Imports ($/Imports) хранились файлы или наборы инструментов из сторонних продуктов (табл. 5-3). Сами сторонние продукты в этой папке не содержались, там были только библиотеки и заголовки. В результате в разделе Imports проводилось совсем немного изменений. Однако так как эта область использовалась для хранения различных версий сторонних продуктов, было очень важно не вносить никаких изменений без чёткого осмысления, полного тестирования и учёта связей с элементами, на которые эти изменения могли бы подействовать.
Табл. 5-3. Примерная структура папки Imports.
$/Imports/RogueWave Библиотеки и заголовки RogueWave
$/Imports/ObjectSpace Библиотеки и заголовки ObjectSpace
$/Imports/Visual С Результаты компиляции, библиотеки и заголовки Visual С
$/Imports/Install Shield Библиотеки и заголовки Install Shield
$/Imports/Прочие Папки для каждого инструмента или библиотеки сторонних производителей
Компоновочная система
В NuMega мы писали сценарий сборки продукта на выделенной «компоновочной машине». Сценарий должен был выбирать нужные для сборки продукта файлы из системы управления исходным кодом. Эта информация включала как сами средства компоновки, так и исходные файлы, библиотеки, заголовки и другие необходимые компоненты. Для ведения процесса компиляции мы выбрали Nmake — популярное средство управления компоновкой. Nmake сначала собирает все части продукта, а затей компонует окончательные исполняемые файлы продукта.
Сценарий компоновки в качестве входных данных принимал метку сборки, позволяло нам создать определённые версии продукта. Так как мы маркировали и отбирали и средства сборки, и файлы продукта, то таким образом мы гарантировали надёжность сборочной среды. Сценарии компоновки также использовали стандартные переменные окружения и макросы, так что мы собирали все части и продукты посредством одного вызова. То, что наша компоновочная машина и разработчики использовали одни и те же сценарии компоновки, позволяло собирать файлы проекта просто и без ошибок.
Надёжная автоматическая система компоновки — необходимое условие успешной разработки. Затраты времени и сил на то, чтобы заставить эту систему работать, своего стоят. Этот и другие вопросы применения технологического ПО обсуждаются в главе 7.
Устранение проблем и неисправностей
Разработка ПО — это динамичный процесс с интенсивным обменом информацией между его участниками. При работе команды над проектом очень важно определить формальные методы поиска и устранения проблем, неисправностей и «жучков», которые постоянно появляются. Применение специальных продуктов для устранения проблем и неисправностей — один из лучших выходов. В оставшейся части главы объясняется, как эффективно использовать такие продукты.
О чём пойдёт речь
ПО для устранения проблем и неисправностей позволяет справляться с бесконечными ошибками и проблемами, всплывающими на поверхность в процессе разработки. Эти программы позволяют членам команды протоколировать, обновлять, назначать, устанавливать приоритет, сортировать и пересматривать информацию, полученную в цикле разработки проекта. Они являются важной частью любого проекта независимо от его размера. Никто не в состоянии запомнить все ошибки и проблемы, которые следует разрешить. И если они не протоколируются, не пересматриваются и для них не устанавливается приоритет, качественного продукта не создать.
Что туда входит
В NuMega использовали систему устранения проблем и неисправностей для хранения любых постоянных или временных данных о проекте, которые только можно было представить. Туда входили все программные ошибки (в том числе функциональные, затрагивающие производительность, процесс установки и параметры, а также все ошибки при сборке) и решения или предложения по улучшению проекта, его настоящих и будущих версий. Здесь действует простой, но очень важный принцип: все данные должны храниться в одном месте. Не следует держать их в хранилище, не обеспечивающем совместное использование, резервное копирование и простой доступ. (Поэтому сообщения электронной почты не подходят!)
Примечание
Я бы не советовал писать собственные программы по устранению проблем и неисправностей, так как хватает различных коммерческих программных продуктов по разумным ценам. Например, Compuware/NuMega TrackRecord, PVCS Tracker, Rational ClearQuest и др. Хотя вам потребуется самим определить, какая из них отвечает вашим потребностям, я настоятельно рекомендую принять решение в пользу покупки. Ведь вы не обязаны тратить время на создание собственных инструментов, ваше дело — поставлять ПО.
Рассмотрим пример. Разработчик замечает, что производительность в одной из частей приложения здорово снизилась, и сообщает об этом по электронной почте в конференцию разработчиков.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73