Всякая порча -- это результат не одного дня, она появляется
после многих поколений, если они были нерадивы в каком-нибудь отношении. Поэтому
здесь на протяжении описания всего процесса постоянно говорится о том, что испорчено
предками и исправляется потомками.
И-Цзин
Слишком много "очевидного"...
Когда одна из бесчисленных бумажек
-- излюбленных атрибутов бюрократического механизма -- появляется на свет и
тем самым начинает свой жизненный цикл (порой весьма непродолжительный), ее
создатель сегодня, даже не задумываясь, использует весьма мощные механизмы если
не полноценного структурирования, то хотя бы визуализации скрытой структуры,
заключенной в "документе". "Красивость" получившегося в
результате -- дело последнее, а вот выделение неявных структурных элементов
шрифтами разного кегля, использование в этих же целях курсива, подчеркиваний
и прочей эквилибристики -- действительно не бюрократическая прихоть или дань
технократической моде. Условно такие механизмы, поддерживаемые всеми современными
текстовыми процессорами и офисными пакетами, можно назвать "структурированием
формой", -- когда сама форма представления документа несет информацию не
только о его структуре, но и о информационной ценности (естественно, это абсолютно
субъективное понятие) элементов этой структуры. Даже короткая записка при грамотном
"структурировании формой" (здесь "грамотность" более подразумевает
понимание сути написанного, чем профессионализм владения разнообразными выразительными
средствами) приобретает очевидное, но никем не формализованное свойство "понятности".
Все это -- вещи сегодня настолько обыденные, что о них уже никто и не говорит.
Но попробуем взглянуть на очевидное иначе... С одной стороны, некая умело
выполненная служебная записка, жизненный цикл которой завершается в мусорной
корзине босса через час-другой после ее создания, интегрирует в себе чуть ли
не все достижения массово доступного инструментария "структурирования формой",
с другой -- исходные тексты огромной программы, создававшейся сотнями людей
на протяжении десятилетий, по сей день остаются чисто текстовыми (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, приведенные в предыдущей
статье, и обеспечивает ряд механизмов, поддерживающих дисциплины управления: