Зачем нужна вся эта путаница с конфигурированием агента почтовой доставки или с установлением на почтовый ящик 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'ом. Однако, я нашел для этого более простой способ.
Какой же из этого можно сделать вывод? Не колебайтесь выбрасывать устаревшие особенности, если вы можете сделать это без потери эффективности. Антуан де Сент–Экзюпери – человек, который был летчиком и авиаконструктором, сказал:
13. Совершенство в разработке достигается не тогда, когда нечего добавить, а тогда когда нечего убрать.
Если ваш код становится одновременно и лучше и проще, вы поступаете правильно. В процессе разработки fetchmail приобрел свое собственное лицо, отличное от старого popclient'a.
Наступило время для смены имени. Новый дизайн больше походил на двойственный sendmail, чем старый popclient. Итак, через два месяца я переименовал его в fetchmail.
7. Fetchmail расширяется.
В работе над этой программой я использовал много изящных нововведений.
Программа работала хорошо, потому что я использовал ее каждый день, и часто прислушивался к моим бета-тестерам. Я вдруг осознал, что это не просто тривиальная хакерская задача, которая может быть полезна разве лишь нескольким людям. У меня была программа нужная каждому хакеру, имеющему UNIX-машину и SLIP/PPP соединение. Благодаря использованию SMPT-forwarding, эта программа могла бы стать «убийцей категории», т. е. программой, которая настолько плотно заполняет свою нишу, что все остальные оказываются просто забытыми.