Языковед. Со времени появления языка алгол-60 выяснилось, что при работе с большинством вычислительных систем нужны один-два профессионала, посвященных во все тонкости языка программирования. Эти специалисты оказались очень полезными, к ним постоянно обращались за консультациями. Они должны обладать совершенно другими талантами, чем хирург, который по самой своей сути является разработчиком систем. Хирург мыслит образами, языковед же может найти красивый и эффективный способ использования языка в трудных, темных или запутанных ситуациях. Зачастую ему придется посвятить два-три дня небольшим исследованиям в поисках хорошего метода. Один языковед может обслуживать двоих или троих хирургов.
Итак, мы предложили способ организации группы программистов, состоящей из 10 человек, и распределение ролей внутри этой группы, используя в качестве модели хирургическую бригаду.
Как она работает? Многие идеи предложенного выше принципа организации коллектива соответствуют нашим требованиям. Десять человек, из них семь профессионалов, работают над проблемой, но система является продуктом одного человека, в крайнем случае - двоих, выступающих как одно целое.
Отметим, в частности, различия между обычным коллективом программистов из двух человек и группой "хирург - второй пилот". Во-первых, в обычных коллектпвах вся работа разделена между сотрудниками, и каждый из них отвечает за разработку и реализацию своей части. В хирургической бригаде и хирург, и BW рой пилот в курсе всего проекта и всей программы. Это снимает проблему дележа памяти, обращений R дискам и т. п. И, кроме того, сохраняется концептуальное единство работы. Во-вторых, в обычных коллективах все сотрудники равны, и неизбежные различия в оценках требуют постоянных обсуждений и компромиссов. Поскольку работа и ресурсы разделены, различия в суждениях, конечно, подчинены общей стратегии и правилам взаимодействия, но они усугубляются противоположностями интересов,- например, чья часть памяти будет использоваться для буфера. В хирургической бригаде нет различий в интересах, а противоречия в мнениях разрешаются самим хирургом единолично. Эти два обстоятельства - единство задачи п связь только по принципу подчинения - позволяют хирургической бригаде действовать как одно целое.
Рис. 3.1. Структура связей в коллективе программистов из 10 человек.
Таким образом, строгое распределение функции между сотрудниками бригады является ключом к повышению ее производительности, поскольку оно, обеспечивает гораздо более простую структуру связей между сотрудниками, как это видно на рис. 3.1.
В статье Бейкера3) рассказывается о проверке принципа хирургической бригады в процессе выполнения одного небольшого проекта. Бригада работала так, как и предполагалось в этом случае, и с очень хорошими результатами.
"Экскалация". Пока все хорошо. Проблема, однако, заключается в том, что же делать с проектами, создание которых требует не 20 или 30, а 5000 человеко-лет. Группа из 10 сотрудников может работать эффективно и независимо от того, как она организована, если только вся задача находится в сфере ее действия. Но как использовать концепцию хирургической бригады применительно к большой задаче, в решении которой принимают участие несколько сот человек?
Залог успеха "эскалации" заключается в том, что нами уже обеспечена высокая степень концептуального единства на уровне частей - в каждой из них число умов, определяющих проект, сократилось в семь раз. Тогда можно отдать всю работу 200 сотрудникам, но проблемы координации поручить 20 хирургам.
Для проблемы координации, однако, надо использовать специальные методы, которые подробно обсуждаются в следующих разделах. Пока же достаточно сказать, что вся система тоже должна обладать концептуальным единством, а ее разработкой должен заниматься системный архитектор. Чтобы обеспечить руководство проектом, необходимо провести четкое различие между архитектурой и реализацией, и системный архитектор должен посвятить себя исключительно архитектуре. Такое распределение ролей и такая методика полностью оправдали себя и оказались очень эффективными.
IV. АРИСТОКРАТИЯ, ДЕМОКРАТИЯ И СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ
"Этот великолепный храм - несравненное произведение искусства. В догмах, которые он утверждает, нет ни черствости, ни беспорядка. Это зенит стиля, работа художников, которые осознали и творчески переработали опыт своих предшественников, полностью овладели методами своего времени, но использовали их, нигде не проявляя никакой чрезмерности. Несомненно, что именно Жан Э'0рбе разработал общий план, которого придерживались, по крайней мере в важнейших чертах, его последователи. В этом заключается, одна из причин полной гармонии всего сооружения".
(Путеводитель по Рейнскому Собору)
Концептуальное единство
Отдельные части всех европейских соборов различаются по своему стилю, потому что они создавались разными поколениями строителей. Каждое новое поколение пыталось "улучшить" старый проект в соответствии с изменениями моды или же различиями индивидуальных вкусов. Спокойный норманский трансепт примыкает к парящему готическому нефу и одновременно противоречит ему, а целое демонстрирует как славу божью, так и самоуверенную гордыню строителей.
На этом фоне архитектурное единство Реймского собора производит, по контрасту, особенно сильное впечатление. Радость, которую испытывает зритель, вызвана в равной мере как единством проекта, так и отдельными его достоинствами. Как говорит путеводитель, этого единства удалось достичь благодаря самоотречению восьми поколений строителей, каждое из которых какую-нибудь свою идею приносило в жертву чистоте замысла. Результат провозглашает не только величие бога, но и величие людей, сумевших преодолеть свою гордыню.
Хотя создание систем программирования и не занимает несколько столетий, почти все они страдают отсутствием концептуального единства, причем в гораздо большей степени, нежели соборы. Обычно это вызвано не последовательной сменой главных разработчиков, а разбиением проекта на множество частей, выполняемых многими людьми.
Я продолжаю настаивать на том, что концептуальное единство является самым важным соображением при проектировании системы. Лучше иметь систему, не имеющую некоторых не слишком существенных свойств, но воплощающую в единое целое множество концепций проектирования, чем систему, содержащую много хороших, но независимых и нескоординированных идей.
В этой и двух последующих главах мы рассмотрим именно эту сторону создания систем программирования и попытаемся ответить на вопросы:
* Как добиться концептуального единства проекта?
* Не подразумевает ли такая постановка проблемы деления на элиту, т. е. аристократов-архитекторов, и серую массу плебеев-программистов, творческие таланты и идеи которых всячески подавляются?
* Как удержать архитектора от витанпя в облаках, от создания нереализуемых или просто дорогих спецификаций?
* Как добиться того, чтобы каждая, даже незначительная деталь спецификации, сделанной архитектором, дошла до исполнителя, была им правильно осмыслена и нашла свое место в конечном продукте?
Как добиться концептуального единства
Система программирования предназначена для того, чтобы облегчить пользование вычислительной машиной. С этой целью создаются -машинные языки и другие различные средства, являющиеся по существу программами. Обращение к ним и управление ими тоже выполняется с помощью машинного языка. Но эти средства весьма дороги: внешнее описание системы программирования стоит в десять-двадцать раз больше, чем внешнее описание самой вычислительной системы. Пользователю гораздо легче самому определить любую требуемую функцию, чем выбрать ц запомнить множество вариантов, форматов и т. п.
Пользование облегчается, если время, выигранное благодаря функциональным возможностям, больше времени, потерянного на изучение, запоминание и поиски в руководствах. В современных системах программирования этот выигрыш - больше затрат, хотя за последнее время отношение выигрыша к затратам уменьшилось в связи с появлением все более сложных функций. Я все еще вспоминаю, как просто было работать на машине IBM-650, даже без ассемблера и вообще без какого бы то ни было программного обеспечения.