Линус сотрудничал со своими пользователями наиболее эффективным способом.
7. Выпускайте ранние релизы. выпускайте частые релизы. Слушайте своих пользователей.
Изобретение Линуса заключается не только в том, что он делал (нечто похожее долгое время было традицией мира UNIX'a). Удивляет уровень интенсивности и сложности того, что он разрабатывал. В начале работы (около 1991 года) бывали случаи, когда новая версия ядра выходила чаще, чем один раз в день.
Это работало, потому что Линус призывал своих пользователей к сотрудничеству через Интернет, активнее, чем кто-либо другой.
Но как это работало? Было ли там что-нибудь, что я мог повторить или дело было в гениальности Линуса Торвальдса?
Я так не думал. Линус – отличный хаккер (кто из нас сможет полностью разработать качественное ядро операционной системы?), но Linux не является принципиальным скачком вперед. Линус – это не гений разработки, такой как, например, Ричард Столмен или Джеймс Гослинг (NeWS или Java). Линус кажется мне скорее гением инженерного мастерства, обладающим шестым чувством избегать ошибки, доводить разработку до конца и с минимальным усилием находить кратчайший путь из точки А в точку В.
Поставленный таким образом вопрос отвечает сам на себя. Сохраняя постоянным отношение числа хакеров к числу пользователей, Линус получал и стимул и вознаграждение. Стимул – удовлетворенность своими действиями, вознаграждение – ежедневное улучшение своей работы.
Линус стремился максимизировать количество человеко-часов, затраченных на отладку и разработку, даже ценой нестабильности, если какая-то ошибка окажется трудно устранимой. Линус считал что:
8. При достаточном количестве бета-тестеров и сотрудников, почти любая проблема будет быстро обнаружена и окажется для кого-то очевидной.
Или менее формально: «При достаточном количестве глаз, ошибки выплывают на поверхность.» Я назову это – законом Линуса.
Мое собственное утверждение состоит в том, что всякая проблема является для кого-то прозрачной. Однако по мнению Линуса, человек, который понимает проблему и находит ее решение, не всегда первый ее обнаруживает. «Кто-то находит проблему», – говорит он, – «А кто-то еще ее понимает. И я часто замечаю, что поиск требует наибольшего навыка.» Суть заключается в том, что и то и другое должно происходить быстро.
Существенная разница здесь в различии соборного и базарного стиля. С точки зрения соборного стиля программирования, ошибки – хитрые, коварные и страшные явления. Месяцы работы, не имеющей отношения к разработке, уходят на то, чтобы выловить все ошибки. Таким образом мы получаем длительные промежутки между релизами и разочарование, когда столь долгожданные релизы оказываются далеки от совершенства.
С другой стороны при работе в стиле базара, вы не считаете ошибки непреодолимым препятствием. По крайней мере они покажутся такими тысячам пользователям, работающим над каждым новым релизом. Вы выпускаете релизы часто, чтобы получить больше исправлений.
Вот и все. Если закон Линуса неверен, то при разработке сложной системы, такой как ядро Linux'a, многими пользователями, в некоторый момент времени, система развалится из-за плохого взаимодействия и недосмотренных серьезных ошибках. С другой стороны, если этот закон верен, то он обЪясняет отностительное отсутствие грубых ошибок.
Возможно, это не так удивительно, как кажется. Несколько лет назад социологи открыли, что среднее мнение людей, в равной степени являющихся либо экспертами, либо дилетантами более верно, чем мнение одного случайно выбранного наблюдателя. Это называется «эффектом Delphi». Линус показал, что это применимо даже в отладке операционной системы, – эффект Delphi может уменьшить сложность проекта даже на уровне разработки ядра ОС.
Я благодарен Джеффу Датки (Jeff Dutky), за то что он показал мне, как можно перефразировать закон Линуса: «Отладка может быть параллельной.» Джефф считает, что хотя во время отладки людям нужно общаться друг с другом с помощью какого-нибудь координатора-разработчика, это не требует серьезной координации между тестерами. Это значительно уменьшает издержки при добавлении тестеров.
На самом деле теоретическая потеря эффективности от того, что часть работы по отладке дублируется, в мире Linux'a очень небольшая. Эффект от частого выпуска релизов уменьшает вероятность двойной работы, так как ошибки фиксируются очень быстро.
Приведем замечание Брукса:' Общая стоимость поддержки широко используемой программы – это не меньше 40% от стоимости ее разработки.' Удивительно, что эта стоимость зависит от числа пользователей. Больше пользователей найдут больше ошибок.
Больше пользователей найдут больше ошибок, потому что новые пользователи добавляют новые способы отладки программы. Этот эффект усиливается, когда пользователи являются сотрудниками. Каждый из них подходит к проблеме выявления ошибок под своим собственным углом. Эффект Delphi в этом случае хорошо работает.
Итак, если мы добавляем больше бета-тестеров, то с точки зрения разработчиков, мы не увеличиваем сложность возможной серьезной ошибки, но увеличиваем вероятность, что кто-то эту ошибку обнаружит, и для него она окажется прозрачной.
На самом деле в ядре Linux'a существуют серьезные ошибки. Однако, нумерация ядра Linux'a производится таким образом, что потенциальные пользователи могут выбрать: использовать стабильную версию или рискнуть и работать с новыми особенностями последней версии. Эта тактика еще не совсем поддерживается большинством хаккеров Linux, хотя возможность выбора делает ее привлекательной.
5. Роза или не Роза?
Изучая работу Линуса и формируя мою собственную теорию о том, почему Linux имеет такой успех, я решил проверить свои измышления на моем новом, значительно менее сложном проекте. Сначала я реорганизовал и упростил popclient. Реализация Карла Харриса была неплохой, однако много С – программистов находило в ней массу сложных и ненужных вещей. Код считался центральной частью, а структуры данных были просто поддержкой кода. В результате код был хорош, но дизайн структур данных по высоким стандартам хаккера, программирующего на LISP'e, был по меньшей мере ужасным.
Однако, у меня была другая цель, отличная от улучшения кода и организации данных. Мне было нужно полное понимание того, что я делаю. Согласитесь, не очень-то здорово отвечать за исправление ошибок в программе, которую ты не понимаешь.
В течение первого месяца, я просто следовал дизайну Карла Харриса. Первым изменением, которое я сделал стала поддержка IMAP-протокола. Я реализовал это, реорганизовав машинные протоколы в общий драйвер и три таблицы методов (для POP2, POP3 и IMAP). Это и предыдущие изменения продемонстрировали общий принцип, который следует помнить хорошему программисту, особенно тем кто пользуется С – подобными языками:
9. Хорошие структуры данных и плохой код работают несколько лучше, чем хороший код и плохие данные.
Брукс Глава 9: 'Если вы покажете мне код и скроете структуры данных, я ничего не пойму в вашей программе. Однако, если вы покажете мне структуры данных, код скорее всего не понадобится. Он будет очевиден. ' Прошло шесть месяцев, и я начал подумывать об изменении имени – это был уже не просто popclient. Однако, я колебался,потому что в дизайне не было ничего принципиально нового. Для уникальности моей версии popclient'a еще очень многого не хватало.
Все значительно изменилось, когда fetchmail научился направлять почту в SMTP порт. Наступил
