Я реализовал эту особенность частично потому, что об этом просили пользователи, а частично потому, что это помогло обнаружить ошибки в single-drop. Мне пришлось обобщить проблему адресации. Усилия себя оправдали. Изучение RFC 822 заняло у меня очень много времени, так как пришлось изучить множество не связанных между собой деталей.
Multidrop-адрессация была замечательным решением. Вот что я из нее вынес:
14. Любой инструмент должен быть полезен для тех целей, для которых он разрабатывался. Великий инструмент становится полезным там, где от него ничего подобного не ожидали.
Другим важным изменеием, сделанным по просьбе моих бета-тестеров, стала поддержка 8-битовой операции MIME. Реализовать это было просто, потому что я старался оставить код 8-битным. Не потому что я чувствовал, что придется реализовывать эту особенность, а потому что я старался следовать следующему правилу:
15. Когда вы разрабатываете gateway software, старайтесь не вмешиваться в поток данных, пока вас к этому не вынудят.
Если бы я не стал следовать этому правилу, поддержка 8-битового MIME, стала бы очень трудной. А так мне просто пришлось прочитать RFC 1652.
Некоторые европейские пользователи просили меня добавить возможность ограничивать число писем за один сеанс (чтобы они могли контролировать издержки своих дорогих телефонных сетей). Я долго сопротивлялся этому, и до сих пор не уверен, что поступил правильно. Однако если вы пишете не только для себя, вы должны слушать ваших покупателей. Независимо от того получаете ли вы от них деньги.
8. Несколько уроков из опыта работы над fetchmail'ом.
Прежде чем мы вернемся к общим рекомендациям по разработке программ, я расскажу о нескольких уроках, которые я вынес из опыта работы над fetcnmail'ом.
Синтаксис файла rc, включает в себя некоторые 'шумные' ключевые слова, которые полностью игнорируются синтаксическим анализатором. Предлагаемый синтаксис (напоминающий английский язык) значительно более читаемый, чем традиционные пары слово-значение, которые вы получите после того, как уберете все лишнее.
Этот эксперимент начался поздно ночью, когда я заметил, насколько объявления в файле rc стали напоминать небольшой императивный язык. (Вот почему я заменил ключевое слово 'server' на 'poll').
Традиционно программисты стремятся использовать точные и краткие управляющие конструкции. Это правильно, потому что вычислительные ресурсы дорогие, и процесс синтаксического анализа должен быть максимально простым и дешевым.
Потому брать за основу английский язык невыгодно, так как в нем около 50% избыточных конструкций.
Для меня это не является причиной, чтобы избегать синтаксиса естественного языка. Дешевое исполнение инструкций и краткость не должны стать конечной целью. В первую очередь язык должен быть удобным для людей, а не дешевым для компьютеров.
Существуют еще несколько поводов для беспокойства. Во-первых, нежелательно, чтобы возросшая стоимость синтаксического анализа, стала сама по себе источником ошибок. Во-вторых, при попытке сделать язык «англоподобным», часто требуется, чтобы «английский» потерял свою форму настолько, чтобы он походил на естественный язык, не больше, чем традиционный синтаксис. (Это можно часто видеть в языках запросов «четвертого поколения» и языках коммерческих баз данных.) В управляющих конструкциях fetchmail'a этих проблем удалось избежать, так как область действия языка сильно ограничена. Он практически не является общецелевым языком,и поэтому несложно перейти от небольшого подмножества английского языка к действительному языку управления. Отсюда можно извлечь еще один урок:
16. Если ваш язык не является полным по Тьюрингу, добавьте немного синтаксического сахара.
Другой урок касается безопасности. Некоторые пользователи fetchmail'a просили меня изменить программу так, чтобы она хранила зашифрованные пароли в файле rc.
Я не сделал этого, потому что это не добавляет никакой защиты. Любой человек, имеющий право читать ваш файл, мог бы запустить fetchmail под вашим именем и, возможно, декодировать ваш пароль. Шифрование пароля в .fetchmailrc могло бы дать людям ложное чувство защищенности. Общее правило здесь следующее:
17. Система безопасности надежна, пока надежны ее секреты. Избегайте псевдо-секретов.
9. Необходимые условия для модели базара.
Читатели ранних версий этой статьи обязательно поднимали вопрос о необходимых условиях для разработки проекта в стиле базара, Здесь обычно рассматривали квалификацию лидера проекта и состояние системы на момент, когда принимается решение опубликовать исходные тексты и создать сообщество сотрудничающих разработчиков.
Очевидно, что никто не сможет начать разработку в таком стиле с нуля. Можно тестировать, отлаживать и улучшать программы, работая в стиле базара, но начать проект очень трудно, Ни я, ни Линус даже не пытались это сделать.
Вашему сообществу разработчиков нужно что-то, что можно отлаживать и тестировать.
Когда вы начинаете создавать сотрудничающее сообщество, вам необходимы убеждающие доводы. Ваша программа может не всегда правильно работать. Она может быть неполной, содержать ошибки или иметь плохую документацию. Однако, она должна обязательно убедить потенциальных сотрудников, в том что их собираются вовлечь в нечто стоящее.
Linux и fetchmail были представлены публике как программы, имеющие строгую основу. Многие люди, когда-либо размышлявшие о модели базара, поначалу относились к этому утверждению критически. Однако позже почти все они приходили к мнению, что лидеру проекта крайне важно иметь высокую квалификацию и интуицию разработчика.
Однако не будем забывать, что Линус заимствовал идеи разработки от UNIX. Я же позаимствовал их у родового popmail'a (хотя мне пришлось переделывать значительно больше, чем Линусу). Так ли уж необходим координатору исключительный талант разработчика или он может использовать чужие идеи?
По-моему не очень существенно, способен ли координатор на оригинальный дизайн. Однако, совершенно необходимо, чтобы лидер проекта был способен отличить хороший дизайн от всех остальных.
И Linux, и fetchmail показали очевидность этого утверждения. Линус – отличный разработчик, который к тому же показал свое умение распознавать хороший дизайн и встраиваить его в ядро Linux. А я, в свою очередь, уже описывал, как единственная наиболее мощная идея в разработке fetchmail (SMTP forwarding) была получена со стороны.
Прежние читатели этой статьи отмечали, что я склонен недооценивать первоначальный дизайн в проектах базара, так как сам я отлично с ним справляюсь, и, поэтому принимаю это как должное. Возможно, в этом есть доля правды, дизайн, в отличие от кодирования и отладки, – мой конек.
Проблема первоначального дизайна заключается в том, что вы начинаете проект, усложняя себе задачу, в то время как следует оставлять ее простой и понятной. Некоторые мои проекты проваливались из-за того, что я совершал эту ошибку, и поэтому я старался не допустить ее при разработке fetchmail.
Итак, я уверен, что fetchmail удался, потому что я ограничил свою изобретательность. Давайте
