我们如何知道哪些功能是有用的？我们没有。这真的是试错。有些功能非常好用。一些你认为没人会在意的功能真的很流行。有些功能只是平淡无奇。工程师的工作就是支持这一点。你需要行动迅速，能够犯错误，并迅速想出一个更大更好的主意。这里有一个很好的例子。1977年8月，一架人力飞机创造了航空史，它绕着一英里的航向飞行，但从未下降到3米以下。把它看作是最小可行的飞机。"薄纱秃鹰"为其发明人保罗·麦克雷亚迪博士赢得了5万英镑的奖金，不到两年后，他设计了它的继任者"薄纱信天翁"，它成功地飞越英吉利海峡英吉利海峡英吉利海峡英吉利海峡英吉利海峡英吉利海峡英吉利海峡，在这个过程中获得了10万英镑的奖金。在20世纪60年代和70年代，一些个人和团体设计了一种人力飞机，试图赢得克雷默奖，这是英国实业家亨利·克雷默在1959年设立的现金奖。尽管其他人成功制造出了短距离飞行的人力飞机，但它们很重，很难控制，甚至在坠毁时更难修复。麦克雷迪的创作灵感来自滑翔机和早期的飞机。它们非常轻巧，使用的技术非常简单，可以快速修复。麦克雷迪意识到问题不在于制造一架可以由人力驱动的飞机，而是制造一架可以在机场维修的飞机。因为这个薄纱可以在跑道上修复，迭代只需几分钟，而不是几个月。我们试图在对讲机上接受类似的工程理念。我们的目标总是以小步走得更快。我们的装运流程可能与贵公司非常相似。就工具而言，没有什么太令人惊讶的。我们使用GitHub编写代码，使用Circle进行测试，然后在AWS上进行登台和生产。没什么争议的。但与许多其他公司不同，我们在前两部分没有花太多时间。他们可能会花上四分之一或半年的时间进行编码和测试，然后再进行大规模部署并投入生产。我们的想法有点不同。我们没有每季度、每月或每周发布新产品，而是每天向客户部署多达50次的新功能。我们做到这一点要归功于一个名为Muster的定制开发工具，它管理我们的基础设施和部署方式。它基于我们在开源世界看到的混合设计，但前提很简单：当出现新的更改时，以可重复部署的方式准备它，并安全地管理部署。它使我们能够安全地回滚并扩展或缩小基础设施的不同部分，而且这样做很快。这不是唯一能帮助我们快速行动的东西。我们不断地在自己身上进行测试，所以特性标记是我们构建产品的一个常规部分。我们将首先向自己发布，然后向一组选定的客户发布，然后向我们的客户发布。这意味着我们会尽早得到反馈，判断某件事是否会成功。但在过去的几年里，有一件事帮助我们实现了许多数量级的快速运输。这是通过转向面向服务的体系结构来实现的。所以，如果你不熟悉，基本的想法是把一个大的应用程序分成许多小的服务，然后从这些小服务中组合出你的大服务。充分披露：技术方面肯定有好处和取舍。有风险，你打开，有一大堆基础设施，你必须到位。但在我的拙见中，面向服务的体系结构对组织的好处远远大于权衡。当你与公司内的团队打交道时，通信开销可以归结为一个API，以及该API上的一些sla。你不需要开很多会议来弄清楚自己到底需要什么。"这是你的API。作为一家产品公司，我们不会仅仅因为它很流行，或者因为编写代码很有趣而重写一大堆代码。我们一直把sla放在桌面上，直到我们发现一个我们认为它很适合的问题。通过快速部署时间和一点一点地交付，您将缩短反馈循环。一个非常好的例子是我们遇到的电子邮件问题。一些客户抱怨他们的许多邮件被标记为垃圾邮件。你可以想象，对于像对讲机这样的公司来说，它的使命是建立在个人，没有垃圾信息，这是一个灾难！所以我们做了一些调查，发现我们有SPF问题。因为我们的许多客户没有配置一个相当神秘的身份验证配置，所以他们的许多邮件最终都在垃圾邮件文件夹中。所以我做了一些挖掘，挑选了一些客户，发送了一些信息，建立了一些文档，并联系了客户，让他们知道："如果你只是把这个记录添加到你的域中，你就会发现你的问题消失了"。反应非常好。问题几乎立刻消失了。那时，我们面临着一个技术问题。以1:1的比例接触客户是不可能的，所以我们需要以某种方式实现自动化。这就是SPF验证服务的用武之地。这样做很自然，因为检查SPF记录并不真正属于Rails应用程序。开始使用面向服务的体系结构是一种安全的方法，因为它不是产品的核心。因为它是解耦的，如果服务失败，它不会对我们所有的用户造成任何错误。如果服务出现问题，人们不会在浏览器中得到500个响应。这是解决我们问题的一个简单、安全的方法。所以我用Dropwizard编写了一些Java，它有一个非常方便的SPF库。（Ruby-one没有友好的授权。）我编写了一个客户端，将其与应用程序连接起来，部署了它，现在我们有了一个服务，它使用标准的对讲机API来查询哪些用户可能会受到影响，然后向他们发送一条消息说，"嘿，你应该去看看。"这只是数百个例子中的一个，我们是如何采取小步行动，支持运送大型、复杂的解决方案来解决我们的问题。在公司成长的过程中，这种以固定的节奏发送小部分有价值代码的奉献精神值得特别注意。如果你的公司成功了，随着时间的推移，很多东西都会成长。你会雇佣更多的人，你会写更多的代码，你的代码库也会增长。所有这些都会增加复杂性，让你慢下来。通过快速的部署时间和一点一点地交付，您将缩短反馈循环，最大限度地减少复杂性和依赖性，这意味着您可以在不断地将代码推向生产时进行调整和学习。