Инструментальная поддержка SCM

20 август, 2002 - 23:00Андрей Зубинский
В первой части этого материала ("Компьютерное Обозрение", # 29, "SCM -- есть такая дисциплина") мы говорили в том числе и о "стандартности", присущей дисциплине управления конфигурацией программного обеспечения. Впрочем, стандартность вовсе не означает шаблонность, и именно поэтому мы начнем очередную беседу, несмотря на название статьи, далеко не "стандартно". А именно -- с рассуждений, весьма очевидных и, вероятно, как раз поэтому так и остающихся рассуждениями.

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

Слишком много "очевидного"...

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

Инструментальная поддержка SCM
"Структурирование формой" с помощью folding-редактора Leo: верхнее горизонтальное окно содержит навигатор-редактор иерархической структурной модели, нижнее -- позволяет редактировать фрагменты текста, поставленные в соответствие элементам структуры. Внутреннее представление такого "дерева" текста (в случае Leo -- это XML-файл) можно, например, автоматически трансформировать в различные внешние формы с помощью поддерживаемых редактором скриптов

Но попробуем взглянуть на очевидное иначе... С одной стороны, некая умело выполненная служебная записка, жизненный цикл которой завершается в мусорной корзине босса через час-другой после ее создания, интегрирует в себе чуть ли не все достижения массово доступного инструментария "структурирования формой", с другой -- исходные тексты огромной программы, создававшейся сотнями людей на протяжении десятилетий, по сей день остаются чисто текстовыми (plain text), лишенными каких-либо дополнительных элементов "формы". Конечно, такое положение вещей имеет и некоторые оправдания, основанные на допущениях, -- программы, в отличие от неформализованных текстов на естественном языке, как будто имеют куда более строгую структуру, а программисты, для которых исходные тексты являются аналогом бизнес-документов, обладают природной, поддержанной образованием и опытом, способностью к логическому и "структурному" мышлению. К сожалению, в инженерии любые, основанные на идеализации представлений о человеке, допущения -- вещь гибельная. Как результат -- в накопленных десятилетиями исходных текстах крайне трудно выделить, например, ключевые элементы программной структуры (а они есть в любой программе, даже весьма тривиальной), понять общие принципы взаимодействия этих элементов и т. д. Подтверждается этот факт наличием сотен инструментальных разработок, направленных именно на облегчение понимания программ. И, опять же, все эти рассуждения весьма обыденны.

Прежде чем сократить дистанцию между темой этого отступления и основной темой статьи, остается определиться с последней "очевидностью" -- "структурой документа". К счастью, это также совершенно тривиальное понятие (по крайней мере, если трактовать его в современных терминах и не пытаться совершать никому не нужные революционные перевороты). В основе основ и всех существующих механизмов описания структур документов, и всех известных подходов к этому описанию лежит понятие иерархической структуры, именуемой "деревом". Технологические нюансы, тонкости и сложности на нашем "макроуровне" совершенно неважны, и принимая это во внимание, ничего иного, кроме "деревьев", в структурах документов мы не отыщем. Если вернуться к нашим прежним рассуждениям о технологии literate programming ("Компьютерное Обозрение", # 20, "Грамотное программирование"), можно вспомнить весьма очевидное (опять же очевидное...) соображение о близости формы представления исходных текстов программы, разработанной по технологии literate programming, и фреймовой формы представления знаний. В свою очередь, фреймы допускают описание в виде графов -- абстракции весьма общей, частным случаем которой являются деревья. Так как мы сейчас говорим не о структуре программного продукта, т. е. не о предмете software engineering, а о попытке сделать главный продукт технологического процесса программирования -- исходные тексты программ -- более пригодными к пониманию и модификациям, вполне допустимо ограничиться формой представления исходных текстов, основанной на деревьях. И, опять же, в качестве доказательства этого допущения можно напомнить о высокой популярности у профессиональных программистов текстовых редакторов, поддерживающих хоть и не совсем полноценную, но действительно удобную функцию древовидной структуризации исходных текстов -- так называемый folding (или outlining). Хороший пример такого кросс-платформенного бесплатного и мощного редактора -- Leo (доступен по адресу personalpages.tds.net/~edream/front.html), в одном из отзывов о котором звучит не только явно подтверждающая все наши прежние рассуждения, но и открывающая путь к дальнейшему изложению фраза: "Leo -- это мощный инструмент для организации текста в древовидные структуры и способ атаки большого количества проблем с помощью основанных на структурировании подходов" (перевод не дословный).

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

Настало время еще одной "очевидности" -- мы уже достаточно знаем, чтобы представить себе... инструментальную поддержку SCM "с высоты птичьего полета". Логично обоснованный минимум такого инструментария может составлять комбинация механизмов редактирования, поддерживающих "структурирование формой", с каким-либо информационным хранилищем, ориентированным на работу с иерархическим (древовидным) представлением данных. К сожалению, даже этот минимальный набор механизмов в большинстве программных систем, в той или иной мере подходящих для программной поддержки дисциплины SCM, реализован далеко не полностью. Обычно "структурирование формой" и соответствующий инструментарий просто игнорируются, информационное хранилище для древовидных структур данных имитируется деревом каталогов файловой системы, а главными "структурообразующими" элементами во всей картине становятся имя файла с исходным текстом, номер строки и ее содержание -- примитивное описание изменения. Если учесть, что существует масса давно отработанных, надежных и доступных folding-редакторов, специализированных баз данных с иерархической моделью (интерес к этим БД значительно увеличился с ростом популярности метаязыка описания древовидных структур, более известного под названием XML), разнообразного инструментария, формализующего операции с древовидными структурами и т. д., остается констатировать последнюю "очевидность": инструментальная поддержка SCM -- область, где кажущееся обилие не балует ни разнообразием, ни изяществом, ни концептуальной целостностью. В этой области достаточно места и для признанных компаний-производителей ПО, и для университетских исследовательских команд, и даже для программистов-одиночек, а возможности качественного использования инструментальных программ определяются не столько их показателями, сколько знанием и принятием дисциплины SCM командой разработчиков.


Переходим на личности

The philosophy is simple, and that makes some of the implementations complex.
Peter Miller

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

Впрочем, и сугубо субъективным выбор предмета нашего разговора назвать нельзя. Субъективны критерии, на основе которых производился выбор, -- SCM-инструментарий должен быть доступным, функциональным, обладать свойством maturity (стабильно развиваться и использоваться на протяжении длительного периода времени) и, естественно, не предъявлять жестких или нечеловеческих требований к потенциальным пользователям. Проще говоря, мы притворимся, что не имеем представления ни о программных "лимузинах" стоимостью в десятки тысяч долларов, ни о "монстрах" с документацией на десятках тысяч страниц, ни о "гаражных поделках", которым без году неделя и у которых все держится "на веревочках".

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

Итак, имя нашей избранницы -- Aegis (иджис), "намертво" вросшее в современный английский язык заимствование древнегреческого названия волшебного непробиваемого щита великого Зевса. Опубликованная в первой версии в далеком 1991 г., достигшая текущей версии 4.7 (на момент выхода еженедельника эта цифра может измениться -- система активно развивается), несколько раз прошедшая процедуры глобального реинжиниринга (самая продолжительная -- 18 месяцев), Aegis с 1990 г. разрабатывается в соответствии с дисциплиной SCM, поддерживаемой... самой Aegis. Ее автор -- Питер Миллер (Peter Miller) --сегодня является и основным разработчиком, и координатором проекта Aegis.

Сразу следует оговориться -- Aegis не кросс-платформенная разработка, в ней использованы специфические вызовы, определенные стандартом POSIX и не имеющие аналогов в Windows-системах. Впрочем, учитывая клиент-серверный характер Aegis, систему можно использовать и в сетевом Windows-окружении как SCM-инструмент, выполняющийся на выделенном Unix-сервере.

Aegis конкретизирует и детализирует определения SCM, приведенные в предыдущей статье, и обеспечивает ряд механизмов, поддерживающих дисциплины управления:

  • декларированием (Manifest control, информация о составе проекта, местонахождении образующих проект элементов и времени включения/исключения элементов из состава проекта);
  • версиями (Version Control, информация о версиях каждого образующего проект элемента и механизм "движения" от версии к версии);
  • сборкой проекта (Build Control, информация о сборке целого из образующих проект элементов);
  • изменениями (Change Control, информация об авторстве и времени всех изменений в проекте);
  • качеством (Quality Control, информация о соответствии показателей качества проекта после внесения изменений заданным требованиям).
О последней дисциплине следует сказать особо. Поддержка управления качеством (Quality Control) -- нечастое явление в мире инструментальных средств SCM, и уж тем более не имеющее явно предпочитаемых разработчиками форм или "стандартных" реализаций. В Aegis оценка качества проекта в его текущей стадии развития осуществляется по единственному критерию -- основная "ось" проекта должна быть "работоспособной". В свою очередь, "работоспособность" здесь тоже термин хитрый -- она означает успешное выполнение всех тестов "оси". И наконец, что очевидно, -- тесты "оси" не могут браться из ниоткуда, и Aegis (как и любая иная система) не может эти тесты "выдумывать" совершенно самостоятельно. Следовательно, в рамках дисциплины, поддерживаемой Aegis, программисты должны не только вносить изменения в исходные тексты программ, но и разрабатывать тесты, сопровождающие эти изменения. Ранее употреблявшееся как очевидное слово "изменение" (change) в терминологии Aegis имеет точно определенное значение: изменение должно быть атомарным (независимым от других изменений, вносимых одновременно) и должно сохранять работоспособность "оси".

Собственно разработка тестов -- тема не одной большой и сложной статьи. И в случае с Aegis понятие "тест" настолько общее, что как раз допускает применение практически любого доступного программного механизма, ведь "тесты" Aegis -- это скрипты на языке командной оболочки sh. Несомненно, из-за обязательности сопровождения каждого изменения тестом есть определенные сложности в случае применения Aegis при проектировании больших программных комплексов с графическим пользовательским интерфейсом (автоматизированное тестирование GUI -- задача хоть и не очень сложная, но иногда слишком непростая и требующая хорошей технологической поддержки), иногда бывает нелегко "увязать" Unix-характер системы с необходимостью тестирования ПО на компьютерах под управлением ОС Windows, но в большинстве случаев эти проблемы разрешимы. В конце концов, Aegis допускает создание проектов без обязательного тестирования.

По мнению подавляющего большинства пользователей Aegis (среди которых преобладают разработчики коммерческого ПО), управлению качеством способствует и требуемая этой системой организационная структура, не дающая возможности разработчикам непосредственно вносить изменения в "ось" проекта. Модификация "оси" -- исключительная привилегия специального пользователя, в терминах Aegis -- "интегратора" (integrator). Именно "интегратор" на основании результатов проверки работоспособности и дополнительных оценок изменения принимает решение о создании новой "оси".

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

В терминах Aegis "обзор кода" (Code Review) -- это неформально (инструментарий и дисциплина не предъявляют никаких требований к форме) составленный документ, в котором отражены замечания, предложения и пр., касающиеся изменения, претендующего на роль "модификатора оси", т. е. речь идет о допустимом изменении, приводящем к работоспособности проекта. Составитель "обзора кода" отражает в своем review то, что может улучшить реализацию проекта (другой стиль программирования, использование иных технологических приемов и т. д.). Aegis гарантирует, что "обозревателем" кода не может быть его автор и что для каждого изменения должен непременно быть хотя бы один обзор кода. Такой жесткой политикой, естественно, можно управлять, например вообще отключить в персональном проекте механизмы Code Review.

Сопоставляя мифологическое значение Aegis с такой сложной и строгой высокоуровневой проектной политикой, можно уверенно говорить -- естественно, в реальном проекте эта система не сыграет роли непробиваемого щита (мы ведь не боги, да и серебряных щитов, как и пуль, не бывает), но все-таки навязываемая системой дисциплина намного лучше хаотически возникающей в коллективном процессе создания ПО анархии. Цепочка "предлагаемое изменение + тест -- проверка работоспособности оси с внесенным предлагаемым изменением -- обзор предлагаемого изменения" может завершиться или одобрением изменения, или "возвратом" его разработчику с соответствующей сопровождающей аннотацией для модификации. При этом проводятся чисто технологические проверки на работоспособность "оси" под воздействием всех накопленных к моменту внесения изменения тестов (!), что обеспечивает раннее обнаружение приходящих с изменением ошибок. Учтены даже весьма сильно сказывающиеся на качестве и производительности коллективной работы психологические факторы -- в частности, авторы обзоров кода могут быть анонимными для программистов. Учитывая и традиционное для мира Unix "невмешательство" Aegis в низкоуровневую и административную политику как оставляющее свободу выбора излюбленного инструментария разработчикам, так и дающее возможность управлять конфигурацией проектного коллектива в целом руководителю, назвать Aegis "прихотливой" программой трудно.

Естественно, высокоуровневая строгость Aegis имеет и обратную сторону. Привилегированный "интегратор", первое лицо Aegis-проекта, начиная с некоторого соотношения между численностью команды разработчиков и размером уже созданного ПО, может просто не справляться со своими обязанностями. Накопительный характер механизма тестов изменений может привести к тому, что в крупном проекте время проверки работоспособности станет большим, чем время между предложениями изменений от разработчиков. Впрочем, еще в середине 90-х годов, когда компьютеры были далеко не такими быстрыми, как сегодня, Aegis неплохо поддерживала проектный процесс в коллективах из 40--60 человек.

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

Эффективность использования Aegis как самостоятельного продукта в проектах среднего масштаба доказана единожды. В некоторых прикладных областях, где не требуется создание GUI-приложений (или используются специфические графические подсистемы), например в разработке ПО для встраиваемых (embedded) систем, Aegis давно и прочно заняла достойное меcто, успешно соревнуясь с куда более именитыми системами аналогичного назначения. Но существенно увеличить отдачу от использования в проектном процессе этой системы можно лишь применяя удачное сочетание инструментария, в первую очередь специфического ПО для тестирования. Специализированные языки описания интерфейсов, в частности хорошо известный благодаря длительному использованию в таких масштабных проектах консорциума X-Open, как X Window, язык ADL (Assertion Definition Language), инструменты автоматизации взаимодействия с неинтерактивными приложениями, статические анализаторы исходных текстов типа Splint -- это далеко не полный перечень доступного и проверенного ПО, позволяющего, например, существенно повысить качество работы "обозревателей", автоматизировать генерацию тестовых заданий для целых подсистем будущей программы на основе их интерфейсов и т. д.


Возвращаясь к "очевидному"

Aegis предлагает весьма неплохую по меркам 90-х годов реализацию хорошей по сей день концептуальной модели инструмента, поддерживающего дисциплину SCM. И, возвращаясь к нашему обсуждению "очевидностей", эта система, как и все остальные ее близкие и далекие аналоги, выполняет вполне очевидные функции -- управляет деревом, представляющим историю версий исходных текстов программного проекта. Использование для этих целей файловой системы и неструктурированного представления plain text приводит к целому ряду ограничений, например к снижению мобильности и жесткости политики механизмов одновременного доступа к исходным текстам. Зато очевидное объединение возможностей структурирующего текстового редактора (такого, как Leo), специфических скриптовых "вставок" и команд Aegis дает возможность с минимальными затратами приблизиться если не к идеалу, то к очень удобной и хорошей системе.