| Беззаконие Брукса? 27.04.2004 Павел Протасов
Также, например, многие утилиты в Linux существуют в нескольких экземплярах. В условиях, когда система строится из «кирпичиков», этот недостаток превращается в достоинство. Итак, когда людские ресурсы ограничены, легче координировать работу, нежели дублировать ее. В условиях неограниченности числа разработчиков из-за недостатка координации возникает дублирование некоторых частей проекта. Это — две стороны одной медали, и между двумя этими процессами необходимо находить баланс, особенно при открытых разработках.
Но стихийно сложившимся сообществом никто не управляет — первая проблема, таким образом, отпадает. А ситуация, когда «не хватает времени», среди свободных разработчиков встречается редко — жестких сроков здесь нет. Обеспечению концептуального единства проекта Брукс уделяет много внимания в четвертой части своей книги, названной «Аристократия, демократическое и системное проектирование». Эпиграфом к главе стоит цитата из путеводителя по Рейнскому собору, и хотя история об этом умалчивает, но весьма вероятно, что эссе Реймонда обязано своим названием как раз Бруксу. Так вот: разработчики GNU/Linux эту концепцию получили готовой, поскольку занимались, в сущности, повторной реализацией Unix-подобной операционной системы. Таким образом, разработка программы методом открытых исходников — не панацея, она была применена к изначально стандартному Unix, что позволило уменьшить роль координаторов между отдельными частями проекта: просто осталось реализовать эти стандартные части заново. Также одной из причин успеха GNU/Linux можно назвать и то, что эта связка первой пришла на массовый рынок и являлась сборником для идей и малых проектов: всегда ведь выгоднее примкнуть к большому проекту, чем затевать свой собственный. Впрочем, здесь уже начинаются скорее психологические проблемы разработки, о которых лучше читать, опять же, у Реймонда [5]. Анализируя вопрос о том, что же представляет собой разработка ядра Linux — «собор» или «базар» (иными словами — централизована ли она или распределена), Николай Безруков высказывает предположение о том, в каком случае какая модель лучше применима: «Для крупных проектов, подобных ОС, особенно важно, чтобы ядро системы разрабатывалось централизованно небольшой тесно сплоченной командой. В то же время при разработке периферийных частей системы более выгоден менее жесткий, более децентрализованный подход» [1]. На первый взгляд может показаться, что это изречение в случае с GNU/Linux на их примере опровергается полностью. Тем не менее мы видим просто путаницу в терминах, вызванную слишком жестким разделением между собой «собора» и «базара». Кстати, в той же работе Безруков проводит параллель между методами разработки ядра и программ Microsoft. Стратегии разработки — повторяются один в один: сначала выпускаем релиз продукта, а затем — используя реакцию пользователей, исправляем в нем ошибки. Разница — в том, что исходники у Microsoft не открыты, и править ошибки приходится самим программистам — по баг-репортам. А пре-релизы в Linux как раз и рассматриваются сообществом как нечто, требующее доработки. Итак, закон Брукса наконец-то берет свое. Позволю себе предложить несколько путей сглаживания его действия. В качестве первого пути можно рассматривать «распараллеливание» работы, то есть продолжение Unix Way, но уже в другой форме. Для этого не обязательно, чтобы проект состоял из отдельных утилит, как GNU. Модульной ведь может быть и графическая ОС. Идея, если честно, была позаимствована у Виктора Вагнера. В статье «True Unix GUI» [3] он описывает концепцию графической оболочки, в которой: - программы строятся из модулей, каждый из которых предназначен для выполнения отдельной задачи; Представьте себе графическую ОС, программы которой можно собирать из функций, как из кирпичиков: комбинировать элементы меню, экранные кнопки, просмотровые модули. При этом программирование для нее превращается в разработку отдельных функций, совместную работу которых в связке обеспечивает сама система. Скажем, модуль, который встраивается в текстовый редактор и при выполнении вызывает функцию, реализуемую отдельной динамической библиотекой или даже стандартным скриптовым языком — допустим, awk или perl. То есть задачей просмотрового модуля становится передача системе данных, с которыми он работает, например текстового файла. Задача системы — передать этот файл отдельному скрипту, который выполнит над ним определенное действие, после чего — вернуть просмотрщику. Ничего невозможного с технической точки зрения я в этом не вижу. Осталось стандартизировать язык, способы взаимодействия модулей между собой и обмена данными. Как мне кажется, у программистов, занимающихся разработкой под свободными Unix-подобными ОС, есть шанс сотворить что-то похожее. Например, уже сейчас существует язык описания интерфейса XUL (www.mozilla.org/projects/xul), способный стать одной из составных частей нашей гипотетической оболочки. Данные, которыми оперирует система, могут иметь в своей основе метастандарт XML. Вторым путем может стать уменьшение числа занятых в проекте программистов. Вообще-то, в свободном программировании это уже наблюдается, по мере того, как от реализации стандартных юниксовых (вернее, работающих стандартным для Unix образом) утилит программисты переходят к созданию независимых проектов. Но хотя, как я уже говорил, людские ресурсы при разработке открытой программы потенциально не ограничены, это относится только к «ассистентам» хирургической бригады. «Хирурги» по-прежнему в цене, и успех проекта зависит главным образом от них. С увеличением количества ПО становится ясно видна тенденция к сокращению числа программистов, работающих над отдельно взятым проектом. Да, исходники открыты, да, можно сделать к ним патч, — но уже ничтожно малый процент пользователей конкретной программы на это способен. Помните, у Честертона отец Браун советовал прятать лист в лесу? Та самая ситуация… Дублирование части работы, которое также наблюдается в открытых проектах, является по большей части неосознанным. Использование сознательного разделения проекта на частично перекрывающиеся между собой группы функций теоретически тоже может быть каким-то образом применено — осталось придумать как… Литература
|
Еще во второй части своей книги Брукс приводит пять причин, по которым программистам не хватает времени для разработки. Две из них — это плохая организация управления ходом разработки и добавление (если становится ясно, что времени не хватает) программистов к группе разработчиков.