Читать интересную книгу Собор и Базар - Эрик Рэймонд

На самом деле теоретическая потеря эффективности от того, что часть работы по отладке дублируется, в мире 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 порт. Наступил день, когда я пришел к этому. Я уже говорил, что я решил использовать этот проект для проверки моей теории о том, что действия Линуса Торвальдса были правильными. Вы спросите, как я делал это? Я использовал для этого следующие способы:

1 – Я часто выпускал релизы(не реже чем каждые 10 дней, а во время периодов интенсивной разработки каждый день.)

2 – Я увеличил список бета тестеров, добавив к нему каждого, кто контактировал со мной на тему fetchmail'a.

3 – Каждый раз когда я делал релиз, я рассылал обЪявления бета-тестерам, приглашая людей активно сотрудничать.

4 – Я слушал своих бета-тестеров и поддерживал с ними обратную связь.

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

10. Если вы относитесь к вашим бета-тестерам как к самому ценному ресурсу, очень скоро они станут вашим самым ценным ресурсом.

Очень интересно было наблюдать за увеличением списка бета-тестеров – друзей feetchmail'a. На время написания в нем было 249 членов, и каждую неделю к ним добавлялись два-три человека.

В мае 1997 года список начал терять своих членов по очень интересной причине. Люди стали отказываться от подписки, потому что fetchmail работал для них настолько хорошо, что необходимость доработки кода отпала.

6. Popclient превращается в Fetchmail.

Все решительно изменилось, когда Харри Хочхейзер принес мне набросок исходного текста для почты в SMTP порт клиентской машины. Я сразу понял, что надежная реализация этой особенности сделает другие режимы доставки практически ненужными.

Размышляя об SMTP forwarding, я понял, что popclient может делать очень много вещей. Я разработал транспортного почтового агента (mail transport agent) и агента локальной доставки (local delivery agent). Используя SMTP forwarding, от MDA можно было избавиться совсем и использовать чистый MTA, доставляя почту другим программам примерно так же, как это делает sendmail.

Зачем нужна вся эта путаница с конфигурированием агента почтовой доставки или с установлением на почтовый ящик lock-and-append, если 25-ый порт почти наверняка находится на каждой платформе с поддержкой TCP/IP?

Отсюда можно извлечь несколько уроков. Во-первых идея об SMTP-forwarding была главным вознаграждением, которое я получил за то, что пытался воспроизвести методы Линуса. Пользователи подкинули мне эту идею и все, что мне оставалось сделать – это понять выводы.

11. Иногда использовать идеи пользователей лучше, чем использовать свои идеи.

Интересно, что чем больше вы сознаете, скольким вы обязаны другим людям, тем больше людей считают, что программа написана вами от начала до конца. Это особенно заметно у Линуса. (Когда я читал эту статью на конференции по Perl'у в августе 1997 года, Larry Wall сидел на первом ряду. Как только я произнес вышенаписанные строки, он воскликнул:" Скажи, скажи им, брат!". Все в зале засмеялись, потому что знали, что он тоже работал над созданием Perl'a.) После нескольких недель работы над проектом в таком духе, я начал чувствовать гордость не только перед своими пользователями, но и перед остальными людьми, которые узнавали обо мне. Я снова и снова смотрел на свою почту и удивлялся, неужели, моя жизнь настолько стоящая.

Однако, существуют более фундаментальные уроки, которые не имеют отношения к политике, зато имеют отношение к общему стилю разработки.

12. Часто самые удивительные решения приходят от понимая того, что постановка задачи была неправильной.

Я пытался решить проблему, разрабатывая popclient как комбинированный MTA/MDA cо всевозможными режимами локальной доставки почты. Разработку fetchmail'a требовалось пересмотреть с позиций чистого MTA.

Когда во время разработки программы вы натыкаетесь на препятствие, когда вам приходится серьезно размышлять над следующим шагом, самое время подумать: но не над тем правильный ли вы получили ответ, а над тем правильный ли вы поставили вопрос. Возможно задачу следует переформулировать.

Итак, я переформулировал свою проблему. Очевидно, что нужно было (1)добавить поддержку SMTP forwarding в родовой драйвер,(2) сделать это режимом по умолчанию, (3)выбросить все остальные режимы доставки, особенно возможности доставки в файл и доставки в стандартный выходной поток.

Некоторе время я не решался делать шаг 3, чтобы не подводить пользователей, зависящих от альтернативных методов доставки. Теоретически, чтобы получить тот же самый эффект они могли переключиться на использование.forward файлов или их не sendmail'овские эквиваленты. Практически, такой переход мог вызвать проблемы.

Однако, когда я решился на этот шаг, он принес много пользы. Значительная часть кода драйвера исчезла, конфигурация заметно упростилась,стало не нужно заботиться об MDA, пользовательском mailbox'e, поддержке блокировки файлов операционной системой.

К тому же исчез единственный способ потерять почту. Если у вас определена доставка почты в файл, а диск оказывается переполненным, то почту вы теряете. Это не может случиться при SMTP forwarding, так как SMTP listener не вернет OK, до тех пор пока сообщение не будет доставлено или отложено для более поздней доставки.

Также улучшилась производительность (хотя при единичном запуске вы бы этого не заметили). Другое незначительное улучшение заключалось в том, что справочная система (manual page) стала короче.

Позже, мне пришлось добавить доставку через локальный MDA определенный пользователем, для того чтобы справиться с некоторыми ситуациями связанными с динамическим SLIP'ом. Однако, я нашел для этого более простой способ.