Linux 版 (精华区)

发信人: pangwa (everything will go end?), 信区: Linux
标  题: (Eric Raymond)大教堂和市集(4)
发信站: 哈工大紫丁香 (Mon Jan 24 14:17:34 2005), 转信

四. 早发布、常发布

　　尽量早尽量频繁的发布是Linux开发模式的一个重要部分，多数开发人员(包
括我)过去都相信这对大型工程来说是个不好的策略，因为早期版本都是些充满错
误的版本，而你不想耗光用户的耐心。
    这种信仰强化了建造大教堂开发方式的必要性，如果目标是让用户尽可能少
的见到错误，那你怎能不会仅仅每六个月发布一次(或更不经常)，而且在发布之
间象一只狗一样辛勤“捉虫”呢? Emacs C内核就是以这种方式开发的，Lisp库，
实际上却相反，因为有一些有FSF控制之外的Lisp库，在那里你可以独立于Emacs
发布周期地找寻新的和开发代码版本。

　　这其中最重要的是Ohio州的elisp库，预示了今天的巨大的Linux库的许多特
征的精神，但是我们很少真正仔细考虑我们在做什么，或者这个库的存在指出了
FSF建造教堂式开发模式的什么问题，1992年我曾经做了一次严肃的尝试，想把
Ohio的大量代码正式合并到Emacs的官方Lisp库中，结果我陷入了政治斗争中，彻
底失败了。

　　但是一年之后，在Linux广泛应用之后，很清楚，一些不同的更加健康的东西
诞生了，Linus的开发模式正好与建造教堂方式相反，Sunsite和tsx-11的库开始
成长，推动了许多发布。所有这些都是闻所未闻的频繁的内核系统的发布所推动
的。

　　Linus以所有实际可能的方式把它的用户作为协作开发人员。

　7. 早发布、常发布、听取客户的建议
　　Linus的创新并不是这个(这在Unix世界中是一个长期传统)，而是把它扩展到
和他所开发的东西的复杂程度相匹配的地步，在早期一天一次发布对他来说都不
是罕见的!而且因为他培育了他的协作开发者基础，比其他任何人更努力地充分利
用了Internet进行合作，所以这确实能行。

　　但是它是怎样进行的呢?它是我能模仿的吗?还是这依赖于Linus的独特天才?

　　我不这样想，我承认Linus是一个极好的黑客(我们有多少人能够做出一个完
整的高质量的操作系统内核?)，但是Linux并不是一个令人敬畏的概念上的飞跃，
Linus不是(至少还不曾是)象Richard stallman或James Gosling一样的创新天
才，在我看来，Linus更象一个工程天才，具有避免错误和开发失败的第六感觉，
掌握了发现从A点到B点代价最小的路径的决窍，确实，Linux的整个设计受益于这
个特质，并反映出Linus的本质上保守和简化设计的方法。

　　如果快速的发布和充分利用Internet不是偶然而是Linus的对代价最小的路径
的洞察力的工程天才的内在部分，那么他极大增强了什么?他创建了什么样的方法?

　　问题回答了它自己，Linus保持他的黑客用户经常受到激励和奖赏：被行动的
自我满足的希望所激励，而奖赏则是经常(甚至每天)都看到工作在进步。

　　Linus直接瞄准了争取最多的投入调试和开发的人时，甚至冒代码不稳定和一
旦有非常棘手的错误而失去用户基础的险，Linus似乎相信下面这个：
　8. 如果有一个足够大的beta测试人员和协作开发人员的基础，几乎所有的问题
都可以被快速的找出并被一些人纠正。

　　或者更不正式的讲：“如果有足够多的眼睛，所有的错误都是浅显的”(群众
的眼睛是雪亮的)，我把这称为“Linus定律”。

　　我最初的表述是每个问题“对某些人是透明的”，Linus反对说，理解和修订
问题的那个人不一定非是甚至往往不是首先发现它的人，“某个人发现了问题”，
他说，“另一个理解它，我认为发现它是个更大的挑战”，但是要点是所有事都趋
向于迅速发生。

　　我认为这是建造教堂和集市模式的核心区别，在建造教堂模式的编程模式看
来，错误和编程问题是狡猾的、阴险的、隐藏很深的现象，花费几个月的仔细检
查，也不能给你多大确保把它们都挑出来的信心，因此很长的发布周期，和在长
期等待之后并没有得到完美的版本发布所引起的失望都是不可避免的。

　　以市集模式观点来看，在另一方面，我们认为错误是浅显的现象，或者至少
当暴露给上千个热切的协作开发人员，让他们来对每个新发布进行测试的时候，
它们很快变得浅显了，所以我们经常发布来获得更多的更正，作为一个有益的副
作用，如果你偶尔做了一个笨拙的修改，也不会损失太多。也许我们本不应该这
样的惊奇，社会学家在几年前已经发现一群相同专业的(或相同无知的)观察者的
平均观点比在其中随机挑选一个来得更加可靠，他们称此为“Delhpi效应”，
Linus所显示的证明在调试一个操作系统时它也适用——Delphi效应甚至可以战胜
操作系统内核一级的复杂度。

　　我受Jeff Dutky (dutky @ wam.umd.edu)的启发指出Linus定律可以重新表述
为“调试可以并行”，Jeff观察到虽然调试工作需要调试人员和对应的开发人员
相交流，但它不需要在调试人员之间进行大量的协调，于是它就没有陷入开发时
遇到的平方复杂度和管理开销。
    在实际中，由于重复劳动而导致的理论上的丧失效率的现象在Linux世界中并
不是一个大问题，“早发布、常发布策略”的一个效果就是利用快速的传播反馈
修订来使重复劳动达到最小。

　　Brooks甚至做了一个与Jeff相关的更精确的观察：“维护一个广泛使用的程
序的成本一般是其开发成本的40%，奇怪的是这个成本受到用户个数的强烈影响，
更多的用户发现更多的错误”(我的强调)。
    更多的用户发现更多的错误是因为更多的用户提供了更多测试程序的方法，
当用户是协作开发人员时这个效果被放大了，每个找寻错误的人都有自己稍微不
同的感觉和分析工具，从不同角度来看待问题。“Delphi效应”似乎因为这个变
体工作变得更加精确，在调试的情况下，这个变体同时减小了重复劳动。

　　所以加入更多的beta测试人员虽不能从开发人员的P.O.V中减小“最深”的错
误的复杂度，但是它增加了这样一种可能性，即某个人的工具和问题正好匹配，
而这个错误对这个人来说是浅显的。

　　Linus也做了一些改进，如果有一些严重的错误，Linux内核的版本在编号上
做了些处理，让用户可以自己选择是运行上一个“稳定”的版本，还是冒遇到错
误的险而得到新特征，这个战略还没被大多数Linux黑客所仿效，但它应该被仿
效，存在两个选择的事实让二者都很吸引人。

--
 飞扬的青春
            自由的享受
                      ----欢迎光临Linux版


※ 修改:·pangwa 于 Jan 24 14:22:21 修改本文·[FROM: 210.46.79.57]
※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 210.46.79.57]