Третий проект. Спецназ Всевышнего - читать онлайн книгу. Автор: Максим Калашников, Сергей Кугушев cтр.№ 217

«…На самом деле, я считаю Линуса одним из самых умнейших людей нашего времени. И… не потому, что он написал ядро „Линукс“, а потому что предложил модель разработки „Линукс“. Когда однажды я сказал это в его присутствии, он улыбнулся и повторил то, что он говорит довольно часто: „На самом деле я – очень ленивый человек, которому нравится приписывать себе то, что на самом деле сделали другие“. Ленивый, как лис. Или, как написал Роберт Хайнлайн в одной из своих статей, „слишком ленивый, чтобы ошибаться“…

…Стиль разработки «Линукса», предложенный Торвальдсом, воспринимался как нечто удивительное. Не как спокойная… атмосфера строительства собора. Вместо этого сообщество «Линукс» напоминало огромный говорливый восточный базар со множеством разнообразных программ и подходов, которые надлежащим образом символизировали узлы и архивы «Линукса», куда отправляли свои решения все, кто хотел… Стабильная и логично связанная система могла возникнуть только благодаря чуду, да и не только одному.

Тот факт, что этот «базарный стиль», по всей видимости, работает, причем работает очень хорошо, вызвал шок. Оглядываясь в прошлое, я понял, что работал не только над конкретными проектами, но также и старался понять: почему мир «Линукс» не только не был погребен в этой хаосе, но, казалось, становился все сильнее и сильней, причем такими темпами, какие трудно представить для традиционных «строителей собора»…

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

Если говорить не столь формально, то при достаточном количестве пользователей все ошибки мельчают. Я назвал это «законом Линуса». Хотя первоначальная формулировка состояла в том, что любая задача для кого-то окажется очевидной, Линус возразил, что человек, который понимает и устраняет проблему – не обязательно и, как правило, не тот человек, который впервые охарактеризовал проблему. «Кто-то находит проблему, – сказал он, – а кто-то ее понимает. Я бы рискнул сказать, что обнаружить проблему намного сложнее». Но суть в том, что в данном случае и то, и другое происходит достаточно быстро.

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

Отличительная особенность ситуации, сложившейся вокруг «Линукса»… стал тот факт, что участники любого данного проекта определяются сами. Один из первых корреспондентов отметил, что вклад в разработку проекта вносят не случайные люди, а те, кто достаточно заинтересован в том, чтобы использовать это программное обеспечение, изучить, как оно работает, попытаться найти решение проблем, с которыми они сталкиваются и действительно найти очевидно разумное решение задачи. Каждый, кто соответствует этим условиям, с большой вероятностью предложит что-то полезное…»

Иными словами, читатель, перед нами – явление из области создания коллективного разума, процесса развертывания программы с помощью сотен и тысяч участников. Процесс идет лавинообразно, когда в дело совершенствования исходной программы вовлекаются все новые и новые ресурсы – причем совершенно добровольно, с большим энтузиазмом. Недостатки, недоработки вскрываются и исправляются очень быстро. И тут же рождается множество улучшений. Все это – гораздо более эффективная схема по сравнению с централизованной. Там, где узкому кругу «избранных умников» требуются годы, здесь срок сжимается до месяцев, а то и дней. В придуманной норвежцем схеме нет «генштаба умников», которые рассматривают себя повелителями над пассивной массой глупцов – здесь есть Общее Дело. Здесь нет отношений «я – начальник, который отдает приказы и навязывает свою волю, а ты – лишь исполнитель». Здесь – сотрудничество в общем проекте. Невозможно в одиночку или небольшой группой предвидеть все нюансы программы, предугадать все ситуации, в которой ей придется работать. Но это способны сделать тысячи соратников-соразработчиков, действуя как одна сверхличность, как «разумная нарастающая лавина», как «мыслящий рой» (или «базар» по Реймонду). И этот принцип, читатель, годится не только для создания компьютерных программ. Важно правильно начать процесс. Впрочем, послушаем-ка Реймонда:

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

…Никто в одиночку не может «с нуля» создать программу, опираясь на «модель базара»…Для зарождения сообщества разработчиков требуется уже работоспособный и готовый к испытаниям продукт…Вам необходимо иметь возможность для того, чтобы предложить правдоподобные обещания. Ваша программа не должна работать особенно хорошо. Она может оказаться «сырой», ошибочной, неполной и плохо документированной. Но она обязательно должна работать и убедить потенциальных соразработчиков в том, что из нее в обозримом будущем может получиться нечто действительно стоящее.

Я считаю, что не так уж важно то, способен ли сам координатор генерировать великолепные архитектурные идеи, но критически важно то, чтобы координатор мог разглядеть прекрасные проектные идеи, предлагаемые другими.

…Координатор и руководитель «базарного проекта» должен уметь работать с людьми…Чтобы создать сообщество разработчиков, нужно уметь привлекать людей, заинтересовывать их и уметь сделать так, чтобы они были довольны тем объемом работы, который выполняют.

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