Беззаконие Брукса?
Культовое эссе Эрика Реймонда "Собор и базар" было опубликовано в 1997 году. Но ни автор, ни критики не анализировали связь разработки свободных программ и классического закона Брукса. Попытаюсь это сделать я.
Автор: Павел Протасов | Раздел: | Дата: 14 мая 2004 года
В 1997 году Эрик Реймонд опубликовал эссе "Собор и базар", мгновенно ставшее поистине культовым. Индекс цитирования этого документа до сих пор зашкаливает за все мыслимые пределы, и происходить это, по-видимому, будет еще долго.
Книга Фредерика Брукса "Мифический человеко-месяц" к тому времени считалась классическим трудом о процессе разработки программ. И один из основных тезисов, выдвинутых Реймондом, гласит, что так называемый закон Брукса неприменим к разработкам, которые делаются через Интернет (например, Fetchmail или ядро Linux).
Ни Реймонд, ни его критики (см., например, Н. Безруков. Повторный взгляд на "Собор и базар"), связь разработки свободных и открытых программ с законом Брукса детальному анализу не подвергали - попытаюсь это сделать я. Примирим, так сказать, огонь и воду.
Закон Брукса
Но прежде - остановимся немного на сущности "закона". Книга Брукса основана на наблюдениях за разработкой операционной системы OS/360, однако сделанные в ней выводы о работе групп программистов справедливы и по сей день. Кстати, нечасто встретишь книгу, посвященную программированию и сохранившую актуальность столь долгий срок.
Одна из возможных формулировок закона Брукса такова: "Если программистский проект не укладывается в сроки, то добавление рабочей силы только задержит его окончание".
Суть же в следующем. Представьте себе группу программистов, совместно работающих над проектом. Результат работы зависит в общем случае от действий каждого из них: кто-то подвел - и срыв всего проекта обеспечен. В "добруксовскую" эру работу коллективов программистов рассчитывали, как правило, просто складывая "человеко-месяцы". Не учитывая при этом внутренние связи в коллективе и время, затрачиваемое на коммуникацию между членами группы. Два месяца работы одного программиста считались равными одному месяцу работы двух программистов. Этот подход хоть и работает в случае с рытьем траншей и переноской тяжестей, для программирования слишком груб.
Брукс впервые показал, что в группе людей, результат работы которых зависит от действий каждого, значительное количество ресурсов может уходить на обеспечение связей между членами группы и между группами, работающими над различными частями проекта. Количество подобных связей можно посчитать с помощью формулы вида n*(n–1)/2, где n - число членов команды.
Принцип, лежащий в основе "закона Брукса", применим и в обычной жизни. Скажем, если нам нужно собрать в одном месте и в одно время энное количество людей, то при оценке вероятности срыва всего мероприятия полезно помнить о том, как именно эта вероятность возрастает. Обеспечить явку троих - в три раза труднее, чем двоих, а четверых - в шесть раз труднее.
Linux: торговцы вокруг храма
"Меня очень удивил стиль разработки Линуса Торвальдса - частый выпуск релизов, доступность всех исходных текстов и терпимость к разнородным программам". Это, по Реймонду, и есть "базарный", децентрализованный стиль разработки. Что же происходит при таком подходе?
Если взглянуть на исходники ядра Linux, то можно заметить, что в подавляющем большинстве случаев у патча к ядру один, реже - два автора. А закон Брукса относится к случаям, когда работа идет в группе из нескольких человек. Двое - это тоже группа, но действие закона здесь заметить трудно: на внутренние коммуникации тратится ничтожно малая доля всех средств и рабочего времени.
Однако Брукс писал и об этом. В третьей части своей книги он анализирует одну основных трудностей при разработке больших программ. С одной стороны, чтобы обеспечить концептуальное единство проекта, группа должна состоять из малого числа разработчиков, каждый из которых может окинуть взглядом проект в целом. С другой стороны - маленькая группа будет писать операционку класса OS/360 лет двадцать.
Решение проблемы Брукс нашел в "хирургических бригадах" - группах разработчиков, каждая из которых отвечает за отдельную часть проекта. При этом собственно проектирование берет на себя только один ведущий программист. Остальные занимаются организационным обеспечением, кодингом, документированием и тому подобной рутиной. Эдак по-стахановски: один уголь рубит, а за ним еще двое укрепляют свод забоя.
Если мы посмотрим на разработку программы fetchmail, то увидим, что создавался этот проект "почти по Бруксу". Действительно, "частый выпуск релизов", который Реймонд называет одной из главных причин успеха открытой разработки, - способ обратной связи с массой разработчиков, присылающих патчи. Стихийные разработчики интуитивно, сами того не замечая, воспроизвели что-то вроде "бригады" простейшего образца: один или несколько "хирургов" и неопределенное количество ассистентов. А в случае с ядром Linux количество людей, присылающих патчи, становится неимоверно большим.
Косвенное подтверждение этому можно увидеть в словах Линуса Торвальдса, процитированных в "Соборе...": "По-моему, не очень существенно, способен ли координатор на оригинальный дизайн. Однако совершенно необходимо, чтобы лидер проекта был способен отличить хороший дизайн от всех остальных". И точно такую же "группу" мы можем увидеть в случае разработки ядра Linux.
Вот он, кстати, тот сакраментальный абзац "Собора и базара", с которого все началось: "В "Мифическом человеко-месяце" Фред Брукс рассматривал различные зависимости времени разработки. Он показывает, что сложность проекта и его коммуникационные издержки квадратично зависят от числа разработчиков, тогда как проделанная работа зависит только линейно. Это утверждение называется законом Брукса, и большинство признает его правильным. Однако если бы дело было только в законе Брукса, Linux не мог бы существовать".
Но в том и дело, что нет никакого "коллектива" разработчиков. Нет командной работы - вместо нее параллельная. Не нужно управлять коллективом - он самоорганизующийся и управляется стихийно. "Хирургическая бригада", о которой Брукс писал лет за двадцать до эссе Реймонда, оказалась, хотя и в несколько нетрадиционной форме, применима и в открытых разработках.
Сам Реймонд в "Соборе и базаре" пытается дать стихийным процессам в разработке обоснование с точки зрения психологии: "Джеральд Венберг в "Психологии программирования" предложил теорию, которую мы можем рассматривать как жизненную поправку к закону Брукса. Обсуждая "неэгоистичное программирование" (egoless programming), Венберг замечает, что если разработчики не являются безраздельными владельцами исходников программ и приветствуют, когда другие люди помогают искать ошибки и предлагают различные улучшения, программа прогрессирует намного быстрее". Впоследствии тема связи психологии и теории игр с программированием нашла продолжение в эссе "Заселяя ноосферу".
Процесс разработки патчей к ядру носит не совсем случайный характер, а зависит от того, какое оборудование появляется на рынке и становится распространенным, от возрастания популярности определенных форматов данных, а также от других потребностей рынка.
Так что можно немного скорректировать ту модель разработки свободных программ, которая описана в "Соборе…". Она представляет собой группу координаторов, ведущих проект в целом и работающих, по терминологии эссе, в стиле "собора". Вокруг них расположена большая группа программистов "базарного" стиля - эти программисты отвечают за мелкие улучшения в исходных текстах.
Примерно такое же мнение высказал в статье "Повторный взгляд на "Собор и базар" один из критиков Реймонда Николай Безруков. Его статья повествует об этом вопросе более подробно и с большим количеством примеров. Мы же пойдем дальше.
Продолжение статьи - на следующей странице.
