Изучая работу Линуса и формируя мою собственную теорию о том, почему 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 работал для них настолько хорошо, что необходимость доработки кода отпала.