информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Атака на InternetSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Модель надежности отказоустойчивой... 
 Facebook хранил часть пользовательских... 
 NSA выпустило Гидру 
 Неприятная уязвимость во всех WinRAR,... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / закон / статьи
ЗАКОН
главная
обозрение
статьи
форум
рассылка
free soft
предложить материал




Paragon Partition Manager 7.0

Беззаконие Брукса?


В середине 1997 года Эриком Реймондом была впервые опубликовано эссе "Собор и базар" [4], ставшее впоследствии поистине культовым. Индекс его цитирования до сих пор зашкаливает за все мыслимые пределы, и происходить это, по-видимому, будет еще долго.

Один из основных тезисов, выдвинутых Реймондом в своей работе – о том, что так называемый "закон Брукса" неприменим к разработкам, которые делаются через Интернет, подобным описанной в статье программы Fetchmail или ядра Linux. Книга Фредерика Брукса "Мифический человеко-месяц" [2], которая к тому времени была книгой о разработке программ, обязательной к изучению, уже лет, наверно, двадцать, представляет собой еще один культовый труд. Ни Реймонд, ни его критики (например, [1]) детальному анализу связь разработки свободных и открытых программ с законом Брукса не подвергали – попытаюсь это сделать я. Примирим, так сказать, между собой два культовых труда.

Закон

Но прежде – остановимся немного на сущности "закона". Книга Брукса основана на наблюдениях за разработкой операционной системы OS/360, однако, сделанные в ней выводы о работе групп программистов применимы и по сей день. Кстати, нечасто встретишь книгу, посвященную программированию и сохранившую актуальность столь долгий срок.

В этой книге Брукс и выдвинул центральный тезис, который впоследствии прозвали "законом" его имени: "Если программистский проект не укладывается в сроки, то добавление рабочей силы только задержит его окончание". Это – одна из многочисленных возможных формулировок.

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

Брукс в своей работе впервые показал, что в группе работников, результат работы которых зависит от действий каждого, довольно значительное количество ресурсов может уходить на обеспечение связей между членами группы и между группами, работающими над различными частями проекта. Количество подобных связей в группе можно посчитать с помощью формулы вида "n(n-1)/2", где n – количество членов команды.

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

Linux: торговцы вокруг храма

"Меня очень удивил стиль разработки Линуса Торвальдса - частый выпуск релизов, доступность всех исходных текстов и терпимость к разнородным программам" [4]. Это, по Реймонду, и есть "базарный", децентрализованный стиль разработки. Что же происходит при таком подходе?

Если взглянуть на исходники ядра Linux, то можно заметить, что в подавляющем большинстве случаев автором патча к ядру является один человек, реже – два. Совсем редко в авторах значится три или более программистов. Закон же Брукса рассматривает случаи, когда работа идет в группе. Разумеется, в случае одного или двух работников его действие заметить трудно: на поддержание работоспособности группы и обмен информацией между ее членами тратится ничтожно малая доля всех средств и рабочего времени.

В такой организации коллектива разработчиков после некоторых усилий удается увидеть так называемую "хирургическую бригаду", о которой Брукс пишет в третьей части своей книги, анализируя одну из основных трудностей при разработке больших программ: с одной стороны, чтобы обеспечить требуемое концептуальное единство операционной системы, нужна группа из сравнительно малого числа разработчиков, каждый из которых способен, так сказать, окинуть взглядом проект в целом, чтобы понять, как работают его составные части. С другой стороны – маленькая группа будет писать операционку класса OS/360 лет примерно двадцать.

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

Если мы посмотрим на разработку программы fetchmail, описанной Реймондом в [4], то увидим очень много общего с "принципом хирургической бригады". Действительно, "частый выпуск релизов", который Реймонд называет одной из основных причин успеха открытой разработки – способ обратной связи с массой разработчиков, присылающих патчи. Стихийные разработчики интуитивно, сами того не замечая, воспроизвели что-то вроде "бригады" самого простого образца: один или несколько "хирургов" и неопределенное количество ассистентов. В случае же с ядром Linux количество людей, присылающих патчи, становится неимоверно большим.

Косвенное подтверждение этому можно увидеть в словах Линуса Торвальдса, процитированных в "Соборе…": "По-моему не очень существенно, способен ли координатор на оригинальный дизайн. Однако, совершенно необходимо, чтобы лидер проекта был способен отличить хороший дизайн от всех остальных". И точно такую же "группу" мы можем увидеть в случае разработки ядра Linux.

Вот он, кстати, тот сакраментальный абзац "Собора и базара", с которого все началось: "В "The Mythical Man-Month" Фред Брукс рассматривал различные зависимости времени разработки. Он показывает, что сложность проекта и его коммуникационные издержки квадратично зависят от числа разработчиков, в то время как проделанная работа зависит только линейно. Это утверждение называется "закон Брукса", и большинство признает его правильным. Однако, если бы дело было только в законе Брукса, Linux не мог бы существовать".

Но в том и дело, что нет никакого "коллектива" разработчиков. Нет командной работы – вместо нее параллельная. Не нужно управлять коллективом – он самоорганизующийся и управляется стихийно. "Хирургическая бригада" о которой Брукс писал лет за двадцать до эссе Реймонда, оказалась, хотя и в несколько нетрадиционной форме, применима и в открытых разработках.

Сам Реймонд в [4] пытается дать стихийным процессам в разработке обоснование с точки зрения психологии: "Пять месяцев назад, Джеральд Венберг в "Психологии программирования" предложил теорию, которую мы можем рассматривать, как жизненную поправку к закону Брукса. Обсуждая "неэгоистичное программирование" (egoless programming), Венберг замечает, что если разработчики не являются безраздельными владельцами исходников программ и приветствуют, когда другие люди помогают искать ошибки и предлагают различные улучшения, программа прогрессирует намного быстрее". Впоследствии тема связи психологии и теории игр с программированием нашла продолжение в эссе "Заселяя ноосферу" [5], которое я также всем рекомендую к прочтению.

Процесс разработки патчей к ядру носит не совсем случайный характер, а зависит от того, какое оборудование появляется на рынке и становится распространенным, возрастания популярности определенных форматов данных, а также других потребностей рынка. Именно поэтому наиболее популярное оборудование и устройства поддерживаются в GNU/Linux, а экзотические – не всегда.

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

Примерно такое же мнение высказал в статье "Повторный взгляд на "Собор и базар" [1] один из критиков Реймонда Николай Безруков. Его статья об этом вопросе повествует более подробно и с большим количеством примеров, так что всем заинтересовавшихся рекомендую прочитать еще и ее. А мы пойдем дальше.

GNU: соборы на базаре

…И перейдем от ядра Linux к собственно операционной системе. Посмотрим теперь, как идет "стихийная" разработка Unix-подобной системы, на примере проекта GNU. Оговорюсь сразу – GNU периода середины-конца девяностых, примерно совпадающего со временем написания "Собора…".

И самое время сейчас – вспомнить, что же такое из себя представляет так называемый "Unix way". Под этим выражением понимается обычно системная архитектура, при которой в состав ОС входит множество утилит, каждая из которых предназначена для выполнения строго своей функции. Другой основополагающий принцип – перенаправление ввода-вывода, благодаря которому эти утилиты могут обмениваться информацией и работать в связках, которые формируются пользователем.

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

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

Также, например, многие утилиты в Linux существуют в нескольких экземплярах. В условиях, когда система строится из "кирпичиков", этот недостаток превращается в достоинство – пользователь может заменить чем-то не устраивающий его компонент другим вариантом.

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

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

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

Обеспечению концептуального единства проекта Брукс уделяет много внимания в четвертой части своей книги, названную "Аристократия, демократическое и системное проектирование". Эпиграфом к главе стоит цитата из путеводителя по Рейнскому собору и, хотя история об этом и умалчивает, но весьма вероятно, что эссе Реймонда обязано своим названием как раз Бруксу. Так вот: разработчики GNU/Linux эту концепцию получили готовой, поскольку занимались, в сущности, повторной реализацией Unix-подобной операционной системы.

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

Также одной из причин успеха GNU/Linux можно назвать и то, что эта связка первой пришла на массовый рынок и являлась сборником для идей и малых проектов: всегда ведь выгоднее примкнуть к большому проекту, чем основывать свой собственный. Впрочем, здесь уже начинаются уже, скорее психологические проблемы разработки, о которых лучше читать, опять же, Реймонда [5].

Выводы

Весьма ценным при разработке открытых программ будет знание того, что законы, по которым велась большая часть подобных разработок до завоевания GNU/Linux теперешней немереной популярности, не вечны, а обязаны своим существованием главным образом специфике реализуемой операционной системы – в случае с GNU, и, вдобавок, неограниченному количеству разработчиков – в случае с Linux.

Анализируя вопрос о том, что же в действительности представляет собой разработка ядра Linux – "собор" или "базар" (или, иными словами – централизована ли она или распределена), Николай Безруков высказывает предположение о том, в каком случае какая модель лучше применима: "Для крупных проектов, подобных операционным системам, особенно важно, чтобы ядро системы разрабатывалось централизованно небольшой тесно сплоченной командой. В то же время при разработке периферийных частей системы более выгоден менее жесткий, более децентрализованный подход" [1].

На первый взгляд может показаться, что это его изречение в случае с GNU/Linux на их примере опровергается полностью. Однако, вместо этого мы видим просто путаницу в терминах, вызванную слишком жестким разделением между собой "собора" с "базаром".

Кстати, в той же работе Безруков проводит параллель между методами разработки ядра и программ одной небезызвестной компании из Редмонда. Microsoft – помните такую? Стратегии разработки – повторяются один в один: сначала выпускаем релиз продукта, а затем – используя реакцию пользователей, исправляем в нем ошибки. Разница – в том, что исходники у Microisoft не открыты и править ошибки приходится самим программистам – по баг-репортам. А пре-релизы в Linux как раз и рассматриваются сообществом как нечто, требующее доработки.

Итак, закон Брукса берет, наконец, свое. Позволю себе предложить несколько путей сглаживания его действия.

В качестве первого пути можно рассматривать "распараллеливание" работы, то есть, продолжение "Юникс-вея", но уже в другой форме. Не обязательно для этого чтобы проект состоял из отдельных утилит, как GNU. Модульной ведь может быть и графическая ОС.

Идея, если честно, была позаимствована у Виктора Вагнера. В своей статье "True Unix GUI" [3] он описывает концепцию графической оболочки, в которой:

  1. программы строятся из модулей, каждый из которых предназначен для выполнения отдельной задачи;
  2. модули обмениваются между собой информацией с помощью стандартных средств ввода-вывода;
  3. при обмене информацией модули используют регулярные выражения, позволяющие обеспечивать разбор строки, поданной на вход модуля.

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

Идеология Unix как раз подходит для того, чтобы над текстовым интерфейсом надстроить подчиняющийся сходным законам интерфейс графический. Осталось стандартизировать язык, способы взаимодействия модулей между собой и обмена данными. Как мне кажется, у программистов, занимающихся разработкой под свободными юникс-подобными ОС, есть шанс сотворить что-то подобное. Например, уже сейчас существует язык описания интерфейса XUL (http://www.mozilla.org/projects/xul/), могущий стать одной из составных частей нашей гипотетической оболочки. Данные, которыми оперирует система могут иметь в своей основе метастандарт XML.

Разумеется, такой подход, при котором составные части приложений представляют собой сравнительно компактный код, занимающийся одной конкретной функцией, поможет, распараллелив разработку, свести действие "закона Брукса" к минимуму и дать пользователю возможность самому конструировать себе приложения, подобно связкам утилит в "классическом" Unix.

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

С увеличением числа чисто пользовательских программ становится ясно видна тенденция к сокращению числа программистов, работающих над отдельно взятым проектом. Да, исходники открыты, да можно сделать к ним патч – но уже ничтожно малый процент пользователей конкретной программы на это способен. Помните, у Честертона отец Браун советовал прятать лист в лесу? Та самая ситуация…

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

Список использованной литературы:

  1. Н.Безруков. Повторный взгляд на "Собор и базар" // http://www.linux.org.ru/books/GNU/misc/second-look-at-CatB.html
  2. Ф.Брукс Мифический человеко-месяц // http://cs.isa.ac.ru/home/support/DOCS/OTHER/MificalMan/
  3. В.Вагнер. True UNIX GUI // http://www.ice.ru/~vitus/thoughts/true_unix_gui.txt/true_unix_gui.txt
  4. Э.Реймонд. Собор и базар // http://www.libertarium.ru/libertarium/15899
  5. Э.Реймонд. Заселяя ноосферу // http://www.bugtraq.ru/law/articles/noo/index.html

Примечание: данная статья впервые была опубликована в еженедельнике "Компьютера" №16 за 2004 год (http://www.computerra.ru/offline/2004/540/33409/). Если вы хотите ее перепечатать, лучше делать это с вариантом из журнала, который может отличаться от размещенного на сайте. (Перепечатка статей из "Компьютеры" разрешается без получения согласия от редакции при условии проставления ссылки на первоисточник).





Rambler's Top100
Рейтинг@Mail.ru




  Copyright © 2001-2019 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach