📄 00000006.htm
字号:
朋友们)的长度，在创立它的时候已经有249个成员了，而且每个星期增加两到三 <BR>个。 <BR> <BR> 实际上，当我在1997年5月校订它时，这张表开始因为一个有趣的原因而缩短 <BR>了，有几个人请求我把他们从表中去掉，因为fetchmail已经工作的如此之好，他 <BR>们不需要看到这些邮件了!也许这是一个成熟的市集风格工程的生命周期的一部分。 <BR> <BR> 我以前一直在解决错误的问题，把popclient当作MTA和具有许多本地递送模 <BR>式的MDA的结合物，Fetchmail的设计需要从头考虑为一个纯的MTA，做为一个普通 <BR>Internet邮件路径的一部分。 <BR> <BR> 当你在开发中碰了壁时(当你发现自己很难想通下一步时)，那通常不是要问 <BR>自己是否找到正确答案，而是要问是否问了正确问题，也许需要重新构造问题。 <BR> <BR> 于是，我重新构造了我的问题，很清楚，要做的正确的事是(1)把SMTP转发支 <BR>持放在通用驱动程序中，(2)把它做为缺省模式，(3)最终分离所有其他的递送模 <BR>式，尤其是递送到文件和标准输出的选项。 <BR> <BR> 我在第三步上犹豫了一下，担心会让popdiant的长期用户对新的递送方法感 <BR>到烦心，在理论上，他们可以立即转而转发文件或者他们的非sendmail等价物来 <BR>得到同样的效果，在实际中这种转换可能会很麻烦。 <BR> 但是当我这么做之后，证明好处是巨大的，驱动程序代码的冗余的部分消失 <BR>了，配置完全变得简单了——不用屈从于系统MDA和用户的邮箱，也不用为下层 <BR>OS是否支持文件锁定而担心了。 <BR> <BR> 而且，丢失邮件的唯一漏洞也被堵死了，如果你选择了递送到一个文件而磁 <BR>盘已满，你的邮件就会丢失，这在SMTP转发中不会发生，因为SMTP侦听器不会返 <BR>回OK的，除非邮件可以递送成功或至少被缓冲留待以后递送。 <BR> <BR> 还有，性能也改善了(虽然在单次执行中你不会注意到)，这个修改的另一个 <BR>不可忽视的好处是手册变得大大简单了。 <BR> <BR> 后来，为了允许处理一些罕见的情况，包括动态SLIP，我必须回到让用户定 <BR>义本地MDA递送上来，但是我发现了一个更加简单的方法。 <BR> <BR> 所有这些给了我们什么启发呢?如果可以不损失效率，就要毫不犹豫抛弃陈旧 <BR>的特性，Antonine de Saint-Exupery(在他成为经典儿童书籍作家之前是一个飞 <BR>行员和飞机设计师)曾说过： <BR> <BR> 13. “最好的设计不是再也没有什么东西可以添加了，而是再也没有什么东西 <BR>可以去掉。” <BR> <BR> 当你的代码变得更好和更简单时，这就是你知道它是正确的时候了，而且在 <BR>这个过程中，fetehmail的设计具有了自己的特点，而区别于其前身popclient。 <BR> <BR> 现在是改名的时候了，这个新的设计看起来比老popclient更象一个sendmail <BR>的复制品，它们都是MTA，但是Senmail是推然后递送，而新的popclient是拉然后 <BR>递送。于是，在两个月之后，我把它重新命名为fetehmail。 <BR> <BR> 七. Fetchmail成长起来 <BR> <BR> 现在我有了一个简洁和富有创意的设计，工作得很好的代码，因为我每天都 <BR>用它，和一直在增长的beta表，它让我渐渐明白我已经不是在从事只能对少数其 <BR>他人有用的工作中，我写了一个所有有一个Unix邮箱和SLIP／PPP邮件连接的人都 <BR>真正需要的程序。 <BR> <BR> 通过SMTP转发功能，它成为一个潜在的“目录杀手”，远远领先于它的竞争 <BR>者，这个程序如此能干以至于其他的程序不但被放弃简直被忘记了。 <BR> <BR> 我知道你不可以真得瞄准或计划出这样的结果，你只能努力去设计这些强大 <BR>的思想，以后这些结果就好象是不可避免的、自然的、注定了的，得到这种思想 <BR>的唯一办法是获取许多思想，或者用工程化的思考其他人的好主意而超过原来想 <BR>到它的人的设想。 <BR> <BR> Andrew Tanenbanm原来设想建造一个适合386的简单的Unix用做教学，Linus <BR>Torvalels把Andrew的可能想到的Minix可以做什么的概念推进了一步，成长为一 <BR>个极好的东西，同样的(虽然规模较小)，我接受了Card Harris和Harry <BR>Hochheiser的想法，把它们变得更强大，我们都不是人们所浪漫幻想的天才的创 <BR>始人，但是大多数科学和工程和软件开发不是被天才的创始人完成的，这和流传 <BR>的神话恰恰相反。 <BR> <BR> 结果总是执着的原因——实际上，它是每个黑客为之生存的成功!而且它们意 <BR>味着我必须把自己的标准定高一点，为了把fetchmail变得和我所能设想的那样 <BR>好，我必须不仅为我自己的需要写代码，而且也要包括对在我生活围主页外的人 <BR>们的需求的支持，而且同时也要保证程序的简单和健壮。 <BR> <BR> 在实现它之后我首先写的最重要的特征是支持多投——从集中一组用户的邮 <BR>件的邮箱中取出邮件，然后把它路由到每个人手中。 <BR> <BR> 我之所以加上多投功能部分是因为有些用户一直在闹着要它，更是因为我想 <BR>它可以从单投的代码中揭露出错误来，让我完全一般地处理寻址，而且这被证明 <BR>了。正确解释RFC822花了我相当长的时间，不仅因为它的每个单独部分都很难， <BR>而且因为它有一大堆相互依赖的苛刻的细节。 <BR> <BR> 但是多投寻址也成为一个极好的设计决策，由此我知道： <BR> <BR> 14. 任何工具都应该能以预想的方式使用，但是一个伟大的工具提供你没料到 <BR>的功能。 <BR> <BR> Fetchmant多投功能的一个没有料到的用途是在SLIP／PPP的客户端提供邮件 <BR>列表、别名扩展。这意味着一个使用个人机器的人不必持续访问ISP的别名文件就 <BR>能通过一个ISP帐户管理一个邮件列表。我的beta测试员提出的另一个重要的改变 <BR>是支持8位MIME操作，这很容易做，因为我已经仔细的保证了8位代码的清晰，不 <BR>仅因为我预见到了这个特性的需求，而且因为我忠实于另一准则： <BR> <BR> 15. 当写任何种类的网关型程序时，多费点力，尽量少干扰数据流，永远不要 <BR>抛弃信息，除非接收方强迫这么作! <BR> <BR> 如果我不遵从这个准则，那么8位MIME支持将会变得困难和笨拙，现在我所需 <BR>要做的，是只读一下RFC 1652，在产生信头的逻辑加上一点而已。 <BR> <BR> 一些欧洲用户要求我加上一个选项来限制每次会话取得消息数(这样他们就可 <BR>以从昂贵的电话网中控制花费了)，我很长一段时间拒绝这样做，而且我仍然对它 <BR>不很高兴，但是如果你是为了世界而写代码，你必须听取顾客的意见——这并不 <BR>随他们不付给你钱而改变。 <BR> <BR>八. 从Fetchmail得来的另一些教益 <BR> <BR> 在他们回到一般的软件工程问题以前，还有几个从fetchmail得到的教益需要 <BR>思考。 <BR> <BR> rc文件语法包括可选的“noise”关键字，它被扫描器完全忽略了，当你把它 <BR>们全抽取出的时候，关键字／值对更具可读性。 <BR> <BR> 当我注意到rc文件的声明在多大程度上开始象一个微型命令语言时，这是一个 <BR>Late-night的体验(这也是我为什么把popclient原来的“server”关键字改成了 <BR>“poll”)。 <BR> <BR> 对我来说似乎把这个微型命令语言变得更象英语可能会使它更容易使用。现在， <BR>虽然我对经过Emacs和HTML及许多数据库引擎所证实的“把它做成一个语言”的设计 <BR>方式确信不疑，但是我并不是一个通常的“类英语”语法的狂热拥护者。 <BR> <BR> 传统程序员容易控制语法使它尽量精确和紧凑，完全没有冗余，这是计算机资 <BR>源还很昂贵时遗留下的一种文化传统，所以扫描策略需要尽可能的廉价和简单，而 <BR>具有50%冗余度的英语，看来好象是一个非常不合适的模型。 <BR> <BR> 这并不是我不用类英语语法的原因，我提到这一点是为了推翻它，在更廉价的 <BR>时钟周期与核心的时代，简洁并没有走到尽头，今天对一个语言来说，对人更方便 <BR>比对机器更廉价来的更加重要。 <BR> <BR> 然而，有几个原因提醒我们小心一点，一个是扫描策略的复杂度开销——你并 <BR>不想把它变成一个巨大的错误来源和让用户困惑，另一个是试图使语言表面上的类 <BR>似可以和传统语言一样令人困惑(你可以在许多4GL和商业数据库查询语言上看到这 <BR>一点)。 <BR> <BR> Fetchmail的控制语法避免了这些问题，因为语言的领域是极其有限的。它一 <BR>点也不象一个一般性的语言，它很简单地描述的东西并不复杂，所以很少可能在英 <BR>语的一个小子集与实际的控制语言之间发生混淆，我想这有一个更广泛的教益： <BR> <BR> 16. 如果你的语言一点也不象是图灵完备的，严格的语法会有好处。 <BR> <BR> 另一个教益是关于安全的，一些fetchmail用户要求我修改软件把口令加密存 <BR>贮在rc文件里，这样觑探者就不能看到它们了。 <BR> <BR> 我没有这样做，因为这实际上起不到任何保护作用，任何有权读取你的rc文件 <BR>的人都可以以你的名义运行fetchmail——如果他们要破你的口令，它们可以从 <BR>fetchmail的代码中找到制作解码器的方法。 <BR> <BR> 所以fetchmail口令的加密都会给那些不慎重思考的人一种安全的错觉，这里 <BR>一般性的准则是： <BR> <BR> 17. 一个安全系统只能和它的秘密一样安全，当心伪安全。 <BR> <BR>九. 集市风格的必要的先决条件 <BR> <BR> 本文的早期评审人员和测试人员坚持提出成功的市集模式开发的先决条件， <BR>包括工程领导人的资格问题和在把项目公开和开始建造一个协作开发人员的社团 <BR>的时候代码的状态。 <BR> <BR> 相当清楚，不能以一个市集模式从头开发一个软件，我们可以以市集模式、 <BR>测试、调试和改进，但是以市集模式从头开始一个项目将是非常困难的，Linus <BR>没有这样做，我也没有，初期的开发人员的社团应该有一此可以运行和测试的 <BR>东西来玩。 <BR> <BR> 当你开始创建社团时，你需要演示的是一个诺言，你的程序不需要工作的 <BR>很好，它可以很粗糙、很笨拙、不完整和缺少文档、它不能忽略的东西是要吸 <BR>引哪些人卷入一个整洁的项目。 <BR> <BR> Linux和fetchmail都是以一个吸引人的基本设计进入公共领域的，许多和 <BR>我一样在思考市集模式的人已经正确的认为这是非常关键的，然后得出了一个 <BR>结论，工程领导者的高度的设计直觉和聪颖是必不可少的。 <BR> <BR> 但是Linus是从Unix得到他的设计的，我最初是从先前的popmail得到启发的 <BR>(虽然相对Linux而言，它最后改变巨大)，所以市集风格的领导人／协调人需要有 <BR>出众的设计才能，或者他可以利用别人的设计才能? <BR> <BR> 我认为能够提出卓越的原始设计思想对协调人来说不是最关键的，但是对 <BR>他／她来说绝对关键的是要能把从他人那里得到的好的设计重新组织起来。 <BR> <BR> Linux和fetchmail项目都显示了这些证据，Linus(如同前面所说)并不是惊人 <BR>的原始设计者，但他显示了发现好的设计并把它集成到Linux内核中的强大决窍。 <BR>还有我也描述了怎样从别人那里得到了fetchmail中最强大的设计思想(SMTP转发)。 <BR> <BR> 本文的早期读者称赞我，说因为我做了许多关于原始设计的事，所以倾向于 <BR>低估原始设计在市集项目中的价值，也许有些是对的吧，但是设计(而不是编码或 <BR>调试)本来就是我最强的能力。 <BR> <BR> 变得聪明和软件设计的原始创作的问题是它会变成一个习惯，当需要保持事 <BR>物健壮和简洁的时候，你却开始把事情变得漂亮但却复杂。我曾经犯过错误，使 <BR>得一些项目因我而崩溃了，但我努力不让它发生在fetchmail身上。 <BR> <BR> 所以我相信fetchmail项目的成功部分是因为我抑制自己不要变得太聪明，这 <BR>说明(至少)对市集模式而言原始设计并不是本质的，请考察一下Linux假设Linus <BR>Torvalds在开发时试图彻底革新操作系统设计，它还会象今天我们所拥有的内核 <BR>那样稳定和成功吗? <BR> <BR>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -