返回正常中文阅读
想对这篇译文“指手画脚”吗？
大错 
小错 
不顺 
建议 When Is a Rose Not a Rose?
When Is a Rose Not a Rose?
Having studied Linus's behavior and formed a theory about why it was successful, I made a conscious decision to test this theory on my new (admittedly much less complex and ambitious) project.
But the first thing I did was reorganize and simplify popclient a lot. Carl Harris's implementation was very sound, but exhibited a kind of unnecessary complexity common to many C programmers. He treated the code as central and the data structures as support for the code. As a result, the code was beautiful but the data structure design ad-hoc and rather ugly (at least by the high standards of this veteran LISP hacker).
I had another purpose for rewriting besides improving the code and the data structure design, however. That was to evolve it into something I understood completely. It's no fun to be responsible for fixing bugs in a program you don't understand.
For the first month or so, then, I was simply following out the implications of Carl's basic design. The first serious change I made was to add IMAP support. I did this by reorganizing the protocol machines into a generic driver and three method tables (for POP2, POP3, and IMAP). This and the previous changes illustrate a general principle that's good for programmers to keep in mind, especially in languages like C that don't naturally do dynamic typing:
9. Smart data structures and dumb code works a lot better than the other way around.
Brooks, Chapter 9: ``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.'' Allowing for thirty years of terminological/cultural shift, it's the same point.
At this point (early September 1996, about six weeks from zero) I started thinking that a name change might be in order—after all, it wasn't just a POP client any more. But I hesitated, because there was as yet nothing genuinely new in the design. My version of popclient had yet to develop an identity of its own.
That changed, radically, when popclient learned how to forward fetched mail to the SMTP port. I'll get to that in a moment. But first: I said earlier that I'd decided to use this project to test my theory about what Linus Torvalds had done right. How (you may well ask) did I do that? In these ways:
- I released early and often (almost never less often than every ten days; during periods of intense development, once a day).
- I grew my beta list by adding to it everyone who contacted me about fetchmail.
- I sent chatty announcements to the beta list whenever I released, encouraging people to participate.
- And I listened to my beta-testers, polling them about design decisions and stroking them whenever they sent in patches and feedback.
The payoff from these simple measures was immediate. From the beginning of the project, I got bug reports of a quality most developers would kill for, often with good fixes attached. I got thoughtful criticism, I got fan mail, I got intelligent feature suggestions. Which leads to:
10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
One interesting measure of fetchmail's success is the sheer size of the project beta list, fetchmail-friends. At the time of latest revision of this paper (November 2000) it has 287 members and is adding two or three a week.
Actually, when I revised in late May 1997 I found the list was beginning to lose members from its high of close to 300 for an interesting reason. Several people have asked me to unsubscribe them because fetchmail is working so well for them that they no longer need to see the list traffic! Perhaps this is part of the normal life-cycle of a mature bazaar-style project.
《大教堂与市集》 第六章 花香何曾随名去？
在研究了李纳斯的作法，并得到他何以成功的理论之后。我决定在我的新项目中（当然没有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端转发的时候，这一切迅速改变了。这个容后再表。首先，我之前说过要在开发过程中验证李纳斯成功的理论，那么（你也会问）我是怎么做到的呢？
- 我早发布，常发布（从未低于十天一次，在高强度的开发周期则每天一次）。
- 我把每个曾和我讨论fetchmail的人都列入公测名单。
- 每当新版本发布，我都会不厌其烦的给公测名单里的每个人寄送一份，并鼓励其参与。
- 我听取公测人员的意见，在设计上征求他们的看法。并且当他们寄回补丁和反馈的时候，给予鼓励。
这些简单的方法立竿见影。在项目一开始，我就收到了很多能让大多数程序员垂涎三尺的高质量错误报告，而且经常还附带不错的修补方法。我还收到过深刻的评论、支持者的来信，高明的功能建议。这一切都证明：
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年）才开始被广泛使用的。所以作者说“历经三十年的文化和术语变迁”。
