…·我把每一个因fetchmail联系我的人都加到beta列表（是指beta测试人员邮件列表——译者注）中。 ·每次发布新版本时，我都向beta列表发送朋友对话般的通知，鼓励他们参与。 ·我听取beta测试者们的意见，征求他们关于设计决策的看法，当他们发来补丁和反馈时给他们以热情回应。 这些简单措施立刻收到了回报。 如果你把beta测试者当做最珍贵的资源对待，他们就会成为你最珍贵的资源。 11.仅次于拥有好主意的是，识别来自用户的好主意，有时后者会更好。 很有趣的是，如果你发自内心地谦逊，并承认你欠别人很多，你将很快发现世界会这样对待你：他们认为是你发明了整个软件，而且你对自己的天赋有着得体的谦虚。我们可以看到这一点在Linus身上体现得有多好！ 通常，那些最有突破性和最有创新力的解决方案来自于你认识到你对问题的基本观念是错的。 设计上的完美不是没有东西可以再加，而是没有东西可以再减。” 当你的代码变得既好又简单，你就知道你做对了， 如果你采用快速迭代开发模式，开发和改进过程就可能成为排错过程的一个特例——修复软件原先在功能或概念上的“疏漏型bug”（bug of omission）。 15.写网关类软件时，尽可能不要干扰数据流，而且绝不要扔掉信息，除非接收方强迫你这么做。 我并不是因此而不喜欢英语语法，相反，提及它正是为了打破传统观念。有了更便宜的计算资源，简洁就不该成为最终目标。对现如今的计算机语言来说，是否便于人类使用要比是否节省计算资源更重要。 当你的语言还远不是图灵完备（Turing-complete）的时候，语法糖[4]会让你受益良多。 17.系统的安全性只取决于它所拥有的秘密。谨防虚假的秘密。 当开始建设社区的时候，你需要拿出一个像样的承诺。程序此时并不需要特别好，它可以简陋、有错、不完整，文档可以少得可怜。但它至少要做到：(a)能运行，(b)让潜在的合作开发者相信，这个软件在可预见的未来，能演变成一个非常棒的东西。 在软件设计上表现得聪明而有原创性，容易养成一个习惯——在应该保持软件健壮性和简单性的时候，你往往下意识把它弄得既华丽又复杂。 此言不虚：最好的程序一开始只是作者对自己每天遭遇问题的个人解决方案，程序流传开来则是因为作者遇到的问题成了一大类用户的典型问题。 想要解决一个有趣的问题，先去找一个让你感兴趣的问题。 一个在封闭项目中只靠自己的开发者，将远远落后于这种开发者：他们知道如何创建一个开放的、有改进能力的环境，在这个环境中，上百人（甚至上千人）反馈并提供设计空间拓展、代码贡献、bug定位以及软件的其他改进。 “齐心协力”正是Linux这种项目所需要的——对Internet上（可以看成是无政府主义者的天堂）的志愿者们使用“命令原则”是根本行不通的。 Linux黑客们致力于最大化的“效用函数”，其目的并不是经典意义上的经济价值，而是自我满足和黑客声望这些无形的东西。（有人把这种动机称为“利他”，但他们忽视了一个事实，即“利他”本身是“利他者”自我满足的外在表现。） fetchmail和Linux核心项目都表明，如果对参与者的“自我”做适当奖赏，一个优秀的开发者或协调者可以利用Internet获取多开发者的好处，而不会让项目陷入混乱不堪。 19.如果开发协调者有一个至少像Internet这样好的沟通媒介，并且知道如何不靠强制来领导，那么多人合作必然强于单兵作战。 未来软件产业的经济关键是服务价值。 一些人认为购买传统模式产品会带来这样的保障：如果项目出错，有人会负责，并为可能的损失买单。 即便很常见，也不要因为可以起诉某人就觉得心安，你想要的不是官司，而是能用的软件。 为弄明白这点，我们需要了解软件开发管理者是如何看待自己工作的，我有位朋友看上去在这方面做得很好，她说软件管理有五个功能：…

…教导客户，就可以和客户建立起传统市场营销策略所无法获得的纽带。通过杂志或网上横幅广告去购买人们的关注力是一方面，如果教育他们，赢得他们的忠诚，建立起完全不同的关系，他们就会更加信任你、更加尊重你。即便他们不用你的产品，仍然会成为你的粉丝。 我之前提过，并不是最出色的产品胜出，而是客户认为最出色的产品胜出。客户如何看待你的公司——如果他们想到的是你的品牌，那么尝试对这种感知进行影响的行为就称为品牌化。 只用了“think different”两个词，就能够让你准确地知道Apple是做什么的，以及你为什么应该关注它。精心制作出这样一条清晰、引人注目的广告词并不容易，但正所谓文案是产品设计最重要的因素（阅读3.1.3节了解更多信息），广告词也是市场推广的核心。产品的宣传口号就是一个很好的例子，它必须能够一下子抓住人们的注意力，让别人知道你的产品有什么不同，而且必须简洁明了。例如，我们看看最初iPod的口号。 Y Combinator的座右铭就是“做人们想要的东西”（make something people want）。这四个简单的单词可以表达出创立成功的创业公司必须了解的几乎一切。 技术栈就是工具，它是实现产品的手段，不是产品的终结，也不是产品本身。不要因为某项技术听起来很酷或者很有趣就选择它，我们选择一种技术是因为它可以为我们所用。为此，应该在把选择技术栈的黄金法则记在心中。 好的技术栈的扩展要快于需要进行的维护。 我们先从需要在很早就做出的一个决定开始：如何为创业公司选择初始的技术栈？我可以只用一句话来回答：熟悉什么就用什么。 当你违背了技术栈的黄金法则——当你发现人数的扩展快于技术的扩展——就是时候重新进行评估了。 暂停所有的发展、在全新的技术栈上重写代码要冒巨大的风险。这种情况被称作“所有软件公司都可能犯的单一的、最糟糕的战略性错误”和“创业自杀”。如果你抛开旧代码，就等于抛开了多年的学习和修复的bug。 一个残忍的事实是：当你的关键业务过程运行在内部情况不清楚（更别提修改）的不透明代码上时，你就失去了对业务的控制。你对供应商的需要超过了供应商对你的需要——因为这一巨大的不平衡，你只能付钱、付钱、再付钱。 任何库复杂到一定的程度之后，都会包含一个临时的、不合规范的、充满程序错误的、运行速度很慢的、只有一半功能的全栈Web框架，这是向格林斯潘的编程第十定律致敬。该定律告诉我们，任何C或Fortran程序复杂到一定程度之后，都会包含一个临时开发的、不合规范的、充满程序错误的、运行速度很慢的、只有一半功能的Common Lisp实现。 如果你正在使用Web框架去实现对业务至关重要的东西——不仅仅只是原型，最好的选择通常就是模块化的全栈框架。那样的话，你可以获得两个方面的好处：一是得到了一个文档完善、有社区支持的开源框架，默认功能就可以出色地处理用户的大部分需求；二是对于小部分特定的情况，也可以通过插入定制库的方法去满足要求。 Web框架很少成为应用程序可扩展性方面的瓶颈（阅读第7章了解更多信息）。所以通常来说，我们最好选择开发效率比较高，而不是处理请求比较快的框架。也就是说，如果你担心性能问题，就需要弄清楚你的应用程序是否有I/O或CPU、内存方面的限制。 安全的实现是非常困难的。它是5.3.4节所列清单中的一项。 我们应该使用内置了安全特性、开源且经过实际检验的框架。因为这不可能是后期再加入的功能，所以框架必须是默认安全的，使我们做不安全的事情也变得困难或不可能。我们要花时间去熟悉常见的Web安全实践方法——开源的Web应用安全项目（Open Web Application Security Project，OWASP）就是一个很好的开始。 我们要花时间去熟悉常见的Web安全实践方法——开源的Web应用安全项目（Open Web Application Security Project，OWASP）就是一个很好的开始。…