大教堂和集市--两种不同的软件开发模式【阅读笔记】

读书时候的阅读笔记，原博客地址：大教堂和集市--两种不同的软件开发模式 论文阅读笔记

大教堂与集市封面.jpg

该博文来自《The Cathedral and the Bazaar》一文的阅读总结，再加入一些自己的理解。今天又发现网上的一个资料，可以说是对本文的一个纲领吧：大教堂与集市--维基语录

1. Given enough eyeballs, all bugs are shallow.【只要眼球足够多 ，所有bug都好捉。】

2. Every good work of software starts by scratching a developer's personal itch.【每一个好的软件的起因都是挠到了开发者本人的痒处。】这里有句话说得很好，很多软件开发人员经常在他们既不需要也不喜欢的程序上消磨时日，换取工资【《黑客与画家》中有类似的描述】。所以说，提起开发者的兴趣和让开发者觉得有意思，那么这个软件就有了一个良好的开头。

3. Good programmers know what to write. Great ones know what to rewrite(and reuse).【好的程序员知道需要写什么，而伟大的程序员知道需要改写（以及重用）什么。】

   在这里，文章以Linus Torvalds由Minix改进为linux为例，解释了尽可能重用前人成果的思想，因此，以后做任何东西，先去linux的世界里，寻找一下是否有别人做的东西比较接近我们想要的最终结果，总比从零开始要容易些。

4. “Plan to throw one away; you will, anyhow.”(Fred Brooks, The Myhical Man-Month, chapter 11)【“计划扔掉一个；无论如何你都会扔掉一个的。”（弗里德.布洛克 《人月神话》第11章）】

   这句话的含义是：在你第一次实现一个方案之前，你通常都没有真正理解你的问题，而第二次实现它时，你或许已经学会了如何把它做对。这句话到今天才懂，联想自己以前编程的例子，比方说毕业设计的时候，第一次实现的过程中才真正了解了问题。这个思想在《代码大全》中也提到过，我们解决问题不可能一蹴而就，通常要解决一次问题，才能真正理解问题。PS：优秀的项目从来不是平白无故出现的，而是需要不断得进化evolve。

5. If you have the right attitude, intresting problems will find you.【如果你有正确的态度，那么你自然会遇到有趣的问题。】

6. When you lose intrest in a program, your last duty to it is to hand it off to a competent successor.【当你对一个项目失去兴趣时，你的最后职责是把它交给一个称职的继承者。】

7. Treating you users as co-developer is your least-hassle route to rapid code improvement and effective debugging.【把用户当做合作者来对待是通往快速改进代码和有效调试的最佳通道。】这一点，说明，一个优秀的软件首先要有用户，所以要解决用户的需求。《需求》这本书中有详细介绍。总结：人多力量大。另外，要有建设性的懒惰，聪明的懒惰，懒惰得像狐狸一样。

8. Release early. Release offen. And listen to your customers.【早发布，常发布，以及听取用户的意见。】

9. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and then fix obvious to someone.【如果beta测试者和合作开发者的群体足够庞大的话，几乎每个问题都会快速现形，然后会有人轻易将它解决。】通俗一点说：只要眼球足够多，所有臭虫都好找，我们称之为“linus法则”。这里提到一个论点：“神庙效应”，即一大群同样内行（或者同样白痴）的观察者的平均预测要比在其中随机选择一个人的预测要可靠得多。箴言：调试是可以并行的。核心开发者和外围开发者。

   在整体上观察到“市集”风格能够很有效得加速调试和代码的优化是一回事儿，从细节上，日常的开发层次上以及开发者和测试者的操作上理解怎样做“市集风格”到和为什么会有这样的效果又是另一回事儿。理解这一点的关键在于：为什么不关心源代码的用户所递交的bug报告一般倾向于无用。因为不关心源代码的用户倾向于只报告表面症状，他们还有两个问题：一是漏掉了关键的前提条件，二是很少能再现bug。在这种情况下，测试者和开发者对程序的模型是不同的，测试者是从外往里看，开发者是从里往外看。开源打破了这种束缚，是的在实在的源代码基础上，在测试者和开发者之间建立了一个共享的模型。

10. Smart data structures and dumb code works a lot better than the other way around.【聪明的数据结构配上丑陋的代码要比相反的情况工作得好得多~】

11. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.【如果你将你的beta测试者当做“最有价值资源”来对待，他们就会以成为“最有价值资源”来回应你。】在这里，要怀有对用户的足够尊敬，尤其是能够在源代码层次上给你提供建议的用户，以满足用户需求为核心价值。

12. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.【比拥有好的主意稍微次要一些的是需要识别那些来自用户的好点子，有时，后者会更好一些。】

13. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. 【当你意识到自己对问题的认识和建模是错误的时候，经常会设计出最优突破和创新的解决方案。】切记：避免用正确的方法解决错误的问题。当在开发中遇到死胡同时，一般来讲是由于你正在解决一个错误的问题，或者需要重新定义问题。

14. "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away."【“设计达到最完美的时候：不是不能再增加功能的时候，而是不能再减少功能的时候。”】箴言：在不损失效率的前提下，要毫不犹豫得把过了气的功能扔掉。当你的代码变得既优良而又简单的时候，你就知道它步上正轨 了。

    箴言：不仅仅调试时可以并行的，开发和搜索设计空间也是。当你的开发模式处于快速迭代过程中时，开发和改进可能成为调试的特例--修正软件原型设计中的不足问题。

15. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.【任何一个工具都应该达到预期的用处和功能，但是一个真正优秀的工具会带给你预期不到的用处。】

16. 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!【在写任何关口软件时候，花点功夫尽可能不要干扰数据流---除非用户强迫你，否则永远不要扔掉任何信息！！】

    箴言：如果你给外边的世界写程序而不是给你自己用，你就不得不聆听你的顾客的要求---就算他们不付你钱也是这个道理。

17. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.【当你的语言离“图灵机完全”还差得 很远的时候，给语言添加点风味可以有帮助。】

18. A security system is only as secure as its secret. Beware of pseudo-secrets.【一个安全系统的安全性取决于它保守的秘密的安全性。要注意伪秘密。】

接下来讨论一下市集风格的必要前提：在市集风格里不能从零开始编程。在开始建立社区时，要有一个这样的程序原型：能运行；能说服潜在的合作者它可以在可预测的将来进化成真正漂亮的软件。主持的人能否想出灿烂的设计不是关键，绝对关键的是主持的人要有足够的智慧识别出他人的优秀设计想法。要避免以下这种坏习惯-----当你应该保持事情稳固和简单的时候，你开始放任得把它们搞得好玩和复杂。对于主持人来说，一定的设计和编码技能的基本水准还是必要的。还有一种和软件开发一般无关的技能，作者认为：对于市集项目来讲，和设计才能一样重要的-----甚至可能更重要，那就是主持市集项目的主持人要有良好的人际、交流技能。要使得市集模式运行起来，你至少有一点点让人们喜欢你的本领，这很重要。

开源软件的社会背景：最好的程序开始于作者日常问题的个人解决方案，又因为一大批人正好都有这个问题而流行。

19. To solve an interesting problem, start by finding a problem that is interesting to you.【要解决一个有意思的问题，首先解决一个你觉得有意思的问题。】

虽然编程基本上仍旧是一种个人封闭的活动，但是真正高超的程序来自于借助整个社区的注意力和脑力。一个在封闭的项目中只使用自己脑力的开发者，将会输给一个知道怎样创造一个开放的、进化式的环境（从中吸收成千或上万人的探索设计空间的反馈、编码贡献、臭虫检测和其他改进）的开发者。

UNIX世界将上述方法发挥到极致的阻碍是：各种执照许可/贸易秘密和商业利益的法律限制；互联网那会还不够好。LINUX进化的两个必要条件是：便宜互联网；一套领导风格和一套合作制度的建立----使得开发者可以吸引合作者、在这个媒介中获取最大程度的收益。而这个制度并不是基于权利去构建，而是按照共同理解的原则去构建。

20. 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.【如果开发人员的协调者有一个至少和互联网一样好的通讯媒介，而且懂得如何不通过强迫来领导，多个人的脑力不可避免得要优于单个人的脑力。】

作者认为：开源软件的未来会更多得属于那些懂得如何运行linus规则的人们，是那些告别大教堂来拥抱集市的人们。

开源项目本质上从不会为了争夺机器或者网路或者办公司间而成立或消亡，它们只会在开发者自己失去兴趣的时候消亡。

传统开发管理是针对缺乏动力的程序员的必要补充，不然他们做不好工作。

结论：开源社区的特点，做事乐在其中。人们一般在一项任务处于一种适当难度范围的时候享有乐趣；不要太简单了以至于无聊，不要太难了以至于不好实现。一个快乐的程序员是一个既没有被浪费也没有被错误制定的目标和烦人的过程摩擦所压倒的人。开源的成功不仅仅是软件开发行业，它教育我们乐趣是创造性工作的经济上最有效的模式。