5. Роза или не Роза?

Изучая работу Линуса и формируя мою собственную теорию о том, почему Linux имеет такой успех, я решил проверить свои измышления на моем новом, значительно менее сложном проекте. Сначала я реорганизовал и упростил popclient. Реализация Карла Харриса была неплохой, однако много C–программистов находило в ней массу сложных и ненужных вещей. Код считался центральной частью, а структуры данных были просто поддержкой кода. В результате код был хорош, но дизайн структур данных по высоким стандартам хакера, программирующего на LISP'e, был по меньшей мере ужасным.

Однако, у меня была другая цель, отличная от улучшения кода и организации данных. Мне было нужно полное понимание того, что я делаю. Согласитесь, не очень-то здорово отвечать за исправление ошибок в программе, которую ты не понимаешь.

В течение первого месяца, я просто следовал дизайну Карла Харриса. Первым изменением, которое я сделал стала поддержка IMAP-протокола. Я реализовал это, реорганизовав машинные протоколы в общий драйвер и три таблицы методов (для POP2, POP3 и IMAP). Это и предыдущие изменения продемонстрировали общий принцип, который следует помнить хорошему программисту, особенно тем кто пользуется C–подобными языками:

9. Хорошие структуры данных и плохой код работают несколько лучше, чем хороший код и плохие данные.

Брукс Глава 9: «Если вы покажете мне код и скроете структуры данных, я ничего не пойму в вашей программе. Однако, если вы покажете мне структуры данных, код скорее всего не понадобится. Он будет очевиден.» Прошло шесть месяцев, и я начал подумывать об изменении имени – это был уже не просто popclient. Однако, я колебался, потому что в дизайне не было ничего принципиально нового. Для уникальности моей версии popclient'a еще очень многого не хватало.

Все значительно изменилось, когда fetchmail научился направлять почту в SMTP порт. Наступил день, когда я пришел к этому. Я уже говорил, что я решил использовать этот проект для проверки моей теории о том, что действия Линуса Торвальдса были правильными. Вы спросите, как я делал это? Я использовал для этого следующие способы:

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

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

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

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

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

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

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

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

Загрузка...