The catherdral and the bazaar / 大教堂和市集

Eric Raymond 有一篇著名文章《大教堂和市集》(The Cathedral and the Bazaar,后来出版成书)。这篇文章是他以Linux核心的开发过程以及他自己主持开发的Fetchmail为案例讨论所写成的软件工程的方法论。文章在1997年5月27号发表于Linux开发者大会上,并于1999年成书出版。

  • Linus Law:Given enough eyeballs, all bugs are shallow。 本文/本书讨论了两种不同的软件开发模式:大教堂模式(The Cathedral model)和 市集模式(The Bazaar model)。原始文章中的大教堂模式包含闭源开发和部分开源项目。但是即使对这部分的开源项目,源代码也是在软件发行后公布。而市集模式则是在开发过程中就公布源代码。大教堂模式让程序排错时间大幅增加,而市集模式则相反。 以我个人的开发经验来看,两种模式的差别不在于程序是否开源/闭源,也不在于何时开源。而是在软体开发过程中有无真实用户直接参与。真实用户无需懂得编程,但是他应该要知道/代表用户核心诉求。用中文的语境来讲,大教堂模式更接近闭门造车(无贬义):一小撮天分极高的人关起门来搞事情。也许搞出的事情牛逼plus,也许搞出来的事情无人问津。
  • 19个教训
    1. 好的软件都起源于程序开发者要解决的切身之痛。Every good work of software starts by scratching a developer's personal itch.
    2. 优秀的程序员知道要写什么程序,伟大的程序员知道要改写(和重复利用)程序。Good programmers know what to write. Great ones know what to rewrite (and reuse).
    3. 计划好好如何舍弃一条路吧,你迟早会遇到这件事情的。Plan to throw one [version] away; you will, anyhow (copied from Frederick Brooks's The Mythical Man-Month).
    4. 如态度正确,则有趣的问题自来。If you have the right attitude, interesting problems will find you.
    5. 当你对某个程序失去兴趣的时候,你最后的责任是找一位能胜任的接班人。When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
    6. 视用户为共同开发者,可以让您在程序改善和排错上事倍功半。Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging
    7. 早发频发版本。倾听用户意见。Release early. Release often. And listen to your customers.
    8. 在一群足够多的beta测试者与共同开发者的情况下,几乎程序里的每一个问题都可以很快地被找到,并且由某个人很简单的解决。Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
    9. 合适的结构体配上笨拙的代码要比相反的组合好。Smart data structures and dumb code works a lot better than the other way around.
    10. 如果你视你的beta版本测试者如果最珍贵的资源,那么他们最终真的就会变成你最珍贵的资源。If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
    11. 从你的用户那里得到的巧思越后面越好。The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
    12. 通常,问题最令人惊讶和最有创意的解决方案通常来源于发掘自己对问题的原始观念是错误的。Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
    13. 完美的设计不是说无法加入更多的东西,而是没有东西可以被移除。Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. (Attributed to Antoine de Saint-Exupéry)
    14. 任何一个以它设计的方式被使用的工具都会是游泳的工具。但是一个真正了不起的工具会以你从未想过的方式来发挥它的功能。Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
    15. 便携任何的通信类软件时,尽可能地保持通讯的信息流—并且不要丢弃其中任何的咨询,飞车你接收方强迫你这么做。When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
    16. 如果你设计的语言不是严谨到要图灵完备,那么你尽可以使用语法糖。When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
    17. 一个保密系统是否安全只取决于它的加密盐。A security system is only as secure as its secret. Beware of pseudo-secrets.
    18. 解决一个有趣的问题,由找到一个让你觉得有趣的问题开始。To solve an interesting problem, start by finding a problem that is interesting to you.
    19. 假设开发协调者有一个至少和互联网一样好的交流媒介,而且他知道如何不靠强迫去引导团队,那么一群人必定胜过一个人。Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.