Scribbles for my bad memory

作者：ERIC S. RAYMOND

2014-12-13 16:28:31
如果你有正确的态度，有趣的事情自然会找到你

2014-12-13 16:29:17
“黑客”并不是媒体报道中的计算机违法分子，而是那种着迷于计算机技术并通过编程提供极具价值软件的人。

2014-12-13 16:30:24
软件膨胀到一定程度，由一个人或几个人继续开发维护就不太现实了，对大型软件来说，多人合作似乎是一种必然，但到底多少人合适，如何分工和组织，如何调动程序员的积极性，如何让软件不会因规模和复杂性而失控，从来都有着不同的方法和认识。

2014-12-13 21:04:08
开放式开发和分布式同行评审（peer review）

2014-12-13 21:12:40
多少双眼睛才能驯服复杂性、要命的最后期限，关于分支和伪分支更准确的定义，进化不利条件理论、孔雀、牡鹿和开源开发者动机的关系，开源的经济学动力，信息不对称效应，用开源做竞争武器。

2014-12-14 10:31:34
白象是一种罕有的白色亚洲象，常作为宗教或王室权利的象征，用来形容昂贵、无用且需要很高代价来维持或经营的事物。

2014-12-14 12:12:58
Linux几乎从一开始就发展出一条完全不同的路，其开发更像是仅通过互联网合作的大量志愿者的随意之作。在质量方面，没有严格的标准也没有一个强有力的机构来管理，他们只是执行一个简单得有点幼稚的策略：每周发布，并在接下来几天内获取数百个用户的反馈。他们创造了一种类似达尔文“物竞天择”的选择机制，被选择对象则是开发者们所做的种种软件修改。让所有人吃惊的是，这种方式工作得非常好。

2014-12-14 12:20:17

并对比两种完全不同的开发模式：绝大多数商业公司所采用的“大教堂”模式和Linux世界采用的“集市”模式。两种模式的根本不同点在于他们对软件排错有着完全对立的认识。我从Linux的经验出发，证实了这样一个命题：“只要眼睛多，bug容易捉。”这和那些由利己个体组成的自纠错系统有着异曲同工之妙。

2014-12-14 12:22:18
早发布、常发布、委托所有能委托的事、开放到几乎是混乱的程度

2014-12-14 13:25:29
好的软件作品，往往源自于开发者的个人需要。

2014-12-14 13:26:13
但太多的软件开发人员并不需要也不热爱他们正在开发的软件，他们把编程当差事，为的只是拿薪酬。

2014-12-14 13:26:58
卓越程序员们有个很重要的特征是“建设性懒惰”，他们知道人们要的是结果而不是勤奋，而从一个部分可行的方案开始，明显要比从零开始容易得多。

2014-12-14 13:31:55
在你第一次把问题解决的时候，你往往并不了解这个问题，第二次你才可能知道怎么把事情做好。所以，如果你想做对事情，至少要再做一次。

2014-12-14 13:33:12
如果你有正确的态度，有趣的事情自然会找到你。

2014-12-14 13:33:36
当你对一个程序不再感兴趣时，你最后的责任就是把它交给一个可以胜任的接棒者。

2014-12-14 13:34:07
拥有用户是一件很美好的事，这不仅表明你正在服务于某种需要，表明你做对了某些事，如果发展得当，他们还会成为你的开发合作者。

2014-12-14 13:34:47
把你的用户当成开发合作者对待，如果想让代码质量快速提升并有效排错，这是最省心的途径。

2014-12-14 13:35:31
Linus最聪明和最有价值的成就其实不是构建出一个Linux内核，而是他发明的这种Linux开发模式。有一次我当面向他表达了这个看法，他笑了，平静地重复了他常说的话：“我基本上是个很懒的人，别人做事，我得名誉。”像狐狸那样懒，或者像Robert Heinlein曾经描绘的一个很有名的角色，太懒以至于无所不能。

2014-12-14 14:17:48
创新、酝酿和行动最频繁发生的地方总是在产品的开放部分，而这部分的改进也总是由庞大而多样化的用户群完成。

2014-12-14 14:19:26
早发布，常发布，倾听用户的反馈。

2014-12-14 14:21:45
Linus在持续不断地激励和回报着他的黑客/用户，用自我满足感激励他们，用持续改进（甚至每天都有改进）回

2014-12-14 14:22:27
Linus的直接目标就是将投入排错和开发的“人时”（person-hour）最大化，即便这样做可能导致代码不稳定，或者可能因为一些难以消除的严重bug导致用户群流失，Linus也在所不惜，他相信：

2014-12-14 14:22:43

8. 如果有足够多的beta测试者 和合作开发者，几乎所有问题都会很快显现，然后自然有人会把它解决。

2014-12-14 14:23:21
那个弄明白并修复问题的人往往不是也没有必要是那个首先发现问题的人，“有人发现问题，”他说，“另有人搞定问题，我可以公开地说，发现问题更具挑战性。”

2014-12-14 14:24:53
，一群专家（或一群无知的家伙）的平均观点要比一个随机选择的人的观点更有预见性，这就是“德尔菲效应”(Delphi effect)。

2014-12-14 14:32:21
对源码不关心的用户，往往报告的都是表面症状，他们把自己的运行环境当成是理所当然的，他们不仅省略了重要的背景数据，而且很少给出重现bug的可靠方法。

2014-12-14 14:32:55
测试者是从外往内看，程序员是从内往外看。对于不开放源码的软件开发，开发者与测试者往往局限于自己的角色，各说各话，都对对方倍感沮丧。

2014-12-14 14:34:41
“在一个已经延期的项目上增加人手，只会让项目更加延期。

2014-12-14 14:35:01
随着开发人员数目的增长，项目复杂度和沟通成本按照人数的平方增加，而工作成果只会呈线性增长。

2014-12-14 14:35:40
，bug很容易集中在不同人写的代码的交互接口上，沟通/协调的开销会随开发者间接口数的增加而增多，也就是说，问题规模和开发人员间的沟通路径数相关，即和人数的平方相关（更精确地讲，应该是N (N-1)/2，N代表开发者数目）。

2014-12-14 14:36:48
在开源项目中，外围开发者实际工作在分散而并行的子任务上，他们之间几乎不交流；代码修改和bug报告都会流向核心团队，只有在那个小的核心团队里才会有Brooks开销。

2014-12-14 14:37:49
要知道开发人员往往离代码太近而不能发现问题

2014-12-14 14:41:36
Carl Harris的实现很好使，但表现出了一种不必要的复杂性，这在C程序员中很常见。他把代码作为最重要部分，而将数据结构置于辅助地位。结果就是，代码很漂亮，但数据结构设计得有点随意和潦草（至少从一个LISP老手的标准来看）。

2014-12-14 14:42:32
一个程序员应该铭记在心的一般原则（尤其对于C这种并不天然支持动态类型的语言）：

9. 聪明的数据结构配上愚笨的代码，远比反过来要好得多。

2014-12-14 14:48:47
我尽早发布并频繁发布（几乎从来没有低于10天一次的频率，在高 •强度开发阶段会一天一次）。我把每一个因fetchmail联系我的人都加到beta列表（是指beta测试人 •员邮件列表——译者注）中。每次发布新版本时，我都向beta列表发送朋友对话般的通知，鼓励 •他们参与。我听取beta测试者们的意见，征求他们关于设计决策的看法，当他 •们发来补丁和反馈时给他们以热情回应。

2014-12-14 14:49:24

10. 如果你把beta测试者当做最珍贵的资源对待，他们就会成为你最珍贵的资源。

2014-12-14 14:56:25
仅次于拥有好主意的是，识别来自用户的好主意，有时后者会更好。
很有趣的是，如果你发自内心地谦逊，并承认你欠别人很多，你将很快发现世界会这样对待你：他们认为是你发明了整个软件，而且你对自己的天赋有着得体的谦虚。

2014-12-14 15:05:31
通常，那些最有突破性和最有创新力的解决方案来自于你认识到你对问题的基本观念是错的。
注: 那些最佳解决方案，往往在你意识到自己一直在解决错误的问题之后才会出现。(找出正确的问题最重要)

2014-12-14 15:06:08
当你发现自己在开发中碰壁时，当你发现自己苦思冥想也很难做出下一个补丁时，通常你不该问自己是否找到了正确答案，而是该问你是否提出了正确的问题，因为也许问题本身需要被重新定义。

2014-12-14 15:07:33
在不损失效能的前提下，不要犹豫，扔掉那些过时的特性吧。

2014-12-14 15:07:59
设计上的完美不是没有东西可以再加，而是没有东西可以再减。

2014-12-14 15:09:36
不仅是排错过程可以并行，开发和设计也可以并行（而且能达到让人惊讶的程度）。如果你采用快速迭代开发模式，开发和改进过程就可能成为排错过程的一个特例——修复软件原先在功能或概念上的“疏漏型bug”（bug of omission）。
注: 把开发新功能按照修复设计缺陷的流程做，就能享受到快速迭代的益处。

2014-12-14 15:12:41
设想下一滩雨水是怎么找到下水口的，或者说蚂蚁是怎么发现食物的。探索在本质上是分散行动，并通过一种可扩展的通信机制来协调整体行为。这很有效，就像Harr y Hochheiser和我，一个外围的游走者可能会在你旁边发现宝藏，而你可能有点过于专注而没能发现。

2014-12-14 15:14:00
大多数科学、工程以及软件开发都不是天才完成的，在青史上留名的往往是黑客。

2014-12-14 15:14:55
任何工具都应具备预期内的功能，但一个伟大的工具能给你带来预期外的功能。

2014-12-14 15:15:48
写网关类软件时，尽可能不要干扰数据流，而且绝不要扔掉信息，除非接收方强迫你这么做。

2014-12-14 15:18:56

17. 系统的安全性只取决于它所拥有的秘密。谨防虚假的秘密。

2014-12-14 15:20:09
当开始建设社区的时候，你需要拿出一个像样的承诺。程序此时并不需要特别好，它可以简陋、有错、不完整，文档可以少得可怜。但它至少要做到：(a)能运行，(b)让潜在的合作开发者相信，这个软件在可预见的未来，能演变成一个非常棒的东西。

2014-12-14 15:22:39
L i nu s是个好人，人们都喜欢他并愿意帮助他，这（和他的项目成功）不是巧合。我精力充沛、性格外向、乐于社交、有一些脱口秀演员般的说话风格和临场反应，这也不是巧合。为了让集市模式运转，哪怕有一点点的人格魅力，都会对你大有裨益。

2014-12-14 15:29:03
想要解决一个有趣的问题，先去找一个让你感兴趣的问题。

2014-12-14 15:30:12
在某些工作场所，开发人员不将代码看作是自己的“领土”，而是鼓励别人发现其中的bug和潜在改进点，这些场所中软件改善速度之快，与别处相比是不可同日而语的。

2014-12-14 15:39:02
真正了不起的作品来自于对整个社区注意力及脑力的有效利用。

2014-12-14 15:47:50
廉价的Internet是Linux模式得以发展的必要条件，但我认为它还不足以成为充分条件。另一个非常重要的因素是领导风格的形成和协作机制的建立，这是吸引合作开发者加入项目的关键，也是充分利用互联网媒介作用的关键。

2014-12-14 15:48:47
“我成长于一个农奴主家庭，在投入积极生活之时，像那个年代所有年轻人一样，我非常相信命令、指示、斥责、惩罚等行为的必要性。但当我早期不得不管理重要事业并和（自由）人打交道时，在任何错误都会立刻导致严重后果时，我开始感悟到按“命令与纪律原则”行事和按“共识原则”行事之间的重要区别。前者在军队检阅时的作用令人钦佩，但在真实生活中却一文不值，想要达到目标，必须要靠众人的齐心协力。”
注: 人心齐，泰山移。

2014-12-14 15:55:58
Linux世界的运转，在很多方面像一个自由市场，或者像一个由很多利己个体组成的生态系统，系统中每个个体都追求自身效用的最大化，在其共生的过程中，能够自然建立起一种具备自我纠错能力的秩序，这种秩序比任何集中式规划都要精妙和高效。

2014-12-14 15:56:39
Linux黑客们致力于最大化的“效用函数”，其目的并不是经典意义上的经济价值，而是自我满足和黑客声望这些无形的东西。（有人把这种动机称为“利他”，但他们忽视了一个事实，即“利他”本身是“利他者”自我满足的外在表现。）

2014-12-14 15:58:31
可以把Linus方法看成是创造一个有效率的“egoboo”市场——把一个个黑客的利己动机尽可能牢靠地牵系到一个艰巨的任务目标上，而这个目标只有在众人持续的合作之下才能达成。正如我在fetchmail项目上所展示的（虽然项目小了点），L inu s方法可以被复制并取得很好效果。

2014-12-14 15:58:01
Linux文档有着令人震惊的广度、深度和质量。程序员痛恨写文档似乎已经成为一个不争的事实，那为什么Linux黑客们还要写出这么多文档？很明显，Linux自由的“egoboo”市场比那些有重金投资的商业软件公司，能够产生更有道德、更利他的行为。

2014-12-14 15:59:02
如果开发协调者有一个至少像Internet这样好的沟通媒介，并且知道如何不靠强制来领导，那么多人合作必然强于单兵作战。

2014-12-14 16:03:49
闭源世界不能赢得一场与开源社区之间的不断演化的军备竞赛，因为后者可以在一个问题上投入比前者多几个数量级的熟练技术工时。

2014-12-14 17:57:29
在一个廉价PC和快速I nternet连接的世界里，我们发现始终如一真正有限的资源是技术人员的关注，开源项目如果失败了，根本不会是因为机器、网络或办公场地，它们死掉的唯一原因就是开发者们不再感兴趣了。

2014-12-14 17:58:04
自愿者自主选择项目，社会环境则无情地选择能力。

2014-12-14 17:58:14
开源之所以成功，部分原因是开源文化只接受编程人员中那最有才华的5%。

2014-12-14 19:31:17
开源社区最强大的一个长项就是非中心化的同行评审，所有致力于细节不被疏漏的传统方法，都无法和它相比。

2014-12-14 18:00:34
比起开源世界由项目领导人和部落长老决定目标的方式，我们需要有好的理由来相信管理委员会和公司路线图所定义的目标在价值上以及在让成员广泛接受上能做得更成功。

2014-12-14 18:03:04
传统软件项目中的60%到70%，要么是从未被完成，要么被他们的用户拒绝。

2014-12-14 19:04:37
如果开源社区真的低估了传统管理的价值，那为什么你们中的这么多人都表现出对你们自己流程的不屑？

2014-12-14 19:05:50
人类通常会从一种位于“最佳挑战区”的任务中获得乐趣，也即它不是太容易而让人无聊，也不是太困难而无法完成。

2014-12-14 19:07:19
“玩”是创造性活动中最具经济效能的工作模式。

多看笔记 来自多看 for iOS