全部博文（272）
分类： LINUX
2009-11-27 11:56:16
在研究了李纳斯的作法，并得到他何以成功的理论之后。我决定在我的新项目中（当然没有Linux那么复杂和雄心勃勃）有意地尝试这些理论。
但是我首先要对popclient做大幅的重写和简化。卡尔·哈里斯的代码很扎实，但是却如同大多C程序设计师一样，有种不必要的繁琐。他把代码置于核心，而数据结构作为其支撑。结果代码很漂亮，而数据结构就很特别了，甚至可以说很缭乱了。（至少就LISP老手的标准而言是这样的）
除了改进代码和数据结构，我的重写还有另一层目的，就是要把它演进成一个我完全理解的东西。因为要是你不能对程序了如指掌，维护起来可就不好玩了。
在最初的一个月里，我只是遵循卡尔的设计理念。我所作的第一个重要改变是加入了对IMAP的支持。做法是：把原来的协议支持部分改写成一个通用驱动和三个可调用的方发表（分别针对POP2、POP3和IMAP）。这些变动都阐明了一个程序员需要铭记在心的通用原则（特别是对于像C这样本身不支持动态类型的语言）：
9.精巧的数据结构即使搭配笨拙的程序代码，也比精巧代码加笨拙结构的组合要强得多。
Smart data structures and dumb code works a lot better than the other way around.
布鲁克斯在《人月神话》的第九章中写道：“只给我看你的工作流程却隐藏表单，我将仍然一头雾水。但是如果你给我展示表单，或许不需要流程图，就能柳暗花明了。”[1]哪怕历经三十年的文化和术语变迁，这个观点依旧正确。
这时（1996年9月初，开工后大约六周），我开始考虑要给软件换个名字了。因为毕竟它已经不仅仅是个POP客户端了。但是我在犹豫，因为设计上没有什么新突破，我的popclient需要独具一格。
当popclient学会如何将收取到的邮件再通过本机SMTP端转发的时候，这一切迅速改变了。这个容后再表。首先，我之前说过要在开发过程中验证李纳斯成功的理论，那么（你也会问）我是怎么做到的呢？
这些简单的方法立竿见影。在项目一开始，我就收到了很多能让大多数程序员垂涎三尺的高质量错误报告，而且经常还附带不错的修补方法。我还收到过深刻的评论、支持者的来信，高明的功能建议。这一切都证明：
10.如果你把公测参与者作为最宝贵的资源来对待，那么他们就会成为你最宝贵的资源。
If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
这个项目庞大的公测名单（我称之为“fetchmail之友”）成为衡量fetchmail成功的重要标准。在我最后一次修订本书（2000年11月）的时候，已经有了287个成员，而且每周还要增加两到三名。
实际上，在1997年5月下旬我改写本书的时候发现，发现出于一个有趣的原因，当人数逼近300峰值时就会开始流失成员。一些人要求我把他们从名单中去掉，因为fetchmail对他们而言已经近乎完美了，所以他们不再需要收到通讯了。或许对于一个成熟的市集型项目，这是其正常生命周期的一部分吧。
译者按：
题解：本章原题为“When Is a Rose Not a Rose?”，化典自莎士比亚名句“A Rose, by any other name, would smell as sweet.”（即使玫瑰不再叫做玫瑰，其依然香醇如故），作者这里的反问是说，即使软件的名字变了但是其优良的质量不会变。至于其名称和质量究竟变与没变，将在下文见分晓。
1.其中原文是：“Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious.”在计算机领域flowchart指流程、运作机制、发生过程、在此处可以理解为程序代码。而table则指数据的有序排列，这里可以理解为数据结构。《人月神话》是软件工程方法概论；而且布鲁克斯在写作的时候，现在的计算机词汇还没有产生，比如数据结构（data structures）的说法大致是与其写作同期（1968年）才开始被广泛使用的。所以作者说“历经三十年的文化和术语变迁”。
