选择钻削工艺

也许我职业生涯中发生的最好的一件事就是让凯兰来负责我。我逗留了足够长的时间，看到凯兰的技术决策开始结出硕果。我从中学到了很多，但也因此学到了很多。我现在就不会自由地成为编写数据驱动产品的工程师了！如果凯兰没有在那里如此彻底地将着陆点放在技术选择上。

在离开Etsy的这一年里，我重新唤起了我关心技术的能力。我的思想已经清晰到可以连贯地写下来的地步。接下来的是凯兰格式塔的升华，希望这只会让他略感震惊。

假设每家公司获得大约三个创新代金券。你可以随心所欲地花这些钱，但是供应是固定的，需要很长一段时间。在你达到一定的稳定性和成熟度之后，你可能会得到更多，但总体趋势是高估了你钱包的内容。显然，这个模型是近似的，但我认为它是有帮助的。

如果您选择用NodeJS编写您的网站，那么您刚刚花费了您的一个创新令牌。如果您选择使用MongoDB，那么您只花了一个创新令牌。如果您选择使用已存在一年或不到一年的服务发现技术，您只需花掉您的一个创新令牌。如果您选择编写自己的数据库，天哪，您就有麻烦了。

如果你是一家javascript咨询公司或一家数据库公司，这些选择中的任何一项都可能是明智的。但你可能不是。你可能在为一家公司工作，这家公司至少在表面上正在重新思考全球商业，或者重新发明网络支付，或者追求其他一些合适的史诗般的使命。在这种情况下，将有限的注意力投入到创新ssh上是失败的绝佳方式。或者充其量只能推迟成功[1]。

什么算无聊？这有点棘手。“无聊”不应该和“糟糕”混为一谈。有一些技术既无聊又糟糕[2]。你不应该用这些东西。但有许多技术选择是无聊和好的，或者至少是足够好的。MySQL很无聊。波斯格雷斯很无聊。PHP很无聊。Python很无聊。memcached很无聊。鱿鱼很无聊。克伦很无聊。

无聊(如此受限)的好处是，这些东西的能力被很好地理解了。但更重要的是，他们的失败模式是众所周知的。任何了解我的人都会明白，我现在只是怀着一种无法抗拒的不适感来召唤唐·拉姆斯菲尔德(Don Rumsfeld)的幽灵，但我必须这样做。

已知的未知是这样的：我们不知道当此数据库达到100%CPU时会发生什么。

未知是这样的：天哪，我们甚至没有想到写入统计数据会导致GC暂停。

这两个集合通常都不是空的，即使对于存在了几十年的技术也是如此。但对于闪亮的新技术来说，未知的未知因素要大得多，这一点很重要。

我毫无歉意地认为偏爱枯燥的技术是一件好事，但这并不是需要考虑的唯一因素。技术选择不是孤立的。它们的范围涉及到您的整个团队、组织和从您的选择总数中涌现出来的系统。

向您的公司添加技术是有成本的。作为一个抽象的陈述，这是显而易见的：如果我们已经在使用Ruby，那么将Python添加到混合中感觉并不明智，因为由此产生的复杂性将超过Python的边际效用。但不知何故，当我们谈论Python和Scala，或者MySQL和Redis时，人们失去了理智，抛弃了所有的限制，开始狂热地鼓吹使用最好的工具来完成这项工作。

简而言之，您的功能是将业务问题映射到涉及软件选择的解决方案空间。如果软件的选择真的没有包袱，您确实可以选择一大堆本地最好的工具来解决您的各种问题。

但当然，行李是存在的。我们称这些包袱为“操作”，在较小程度上称为“认知开销”。你得监视这东西。您必须弄清楚单元测试。你需要知道它的第一件事才能破解它。您需要一个初始化脚本。我可以在这里呆上几天，所有这些都会很快积累起来。

“最适合工作的工具”思维的问题在于，它对“最好”和“工作”这两个词的看法过于短视。你的工作就是让公司继续经营，该死的。而“最好的”工具是对尽可能多的问题占据“最不糟糕”位置的工具。

基本上总是这样的，保持系统可靠工作的长期成本远远超过您在构建它时遇到的任何不便。成熟而高效的开发人员明白这一点。

将这一推理推论到荒谬的程度将意味着选择Java，然后尝试在根本不使用任何其他东西的情况下实现一个网站。那就太疯狂了。你需要一些方法来把东西添加到你的工具箱里。

重要的第一步是承认这是一个过程，一个对话。新技术最终会在全公司范围内产生影响，因此增加技术是一个需要全公司可见度的决定。您的组织细节可能会迫使对话，或者它们可能会方便开发人员在不与任何人交谈的情况下添加新的数据库和队列。不管怎样，你必须设定文化期望，这是我们都在谈论的东西。

我在这里推荐的最有价值的练习之一是考虑如何在不增加任何新东西的情况下解决眼前的问题。首先，提出这个问题应该检测到“问题”是某人真的想要使用技术的情况。如果是这样的话，您应该立即中止。

一小套技术选择可以走多远，这可能是令人惊讶的。在实践中，这个问题的答案几乎从来都不是“我们做不到”，它通常只是在“嗯，我们可以做到，但太难了”[4]之间。如果你认为你现在拥有的东西不能实现你的目标，那么你可能就是想得不够创造性。

准确地写下当前堆栈是什么使解决问题的成本和难度高得令人望而却步，这是很有帮助的。这与前面的练习有关，但略有不同。

新的技术选择可能纯粹是相加的(例如：“我们还没有缓存，所以让我们添加memcached”)。但它们也可能会重叠或取代你已经在使用的东西。如果是这样的话，您应该对将旧功能迁移到新系统设定明确的期望。政策通常应该是“我们致力于迁移”，并有一个建议的时间表。这一步骤的目的是将残骸保持在可管理的水平，并避免扩散局部最优解决方案。

这个过程并不令人望而生畏，也不会有太大的麻烦。这是几个要作为家庭作业填写的问题，然后召开会议讨论这个问题。我认为，如果一项新技术(或要在您的基础设施上创建的新服务)能够毫发无损地通过这一挑战，那就很好了。

多语种编程的销售承诺是让开发人员完全自由地选择他们自己的工具，这将使他们在解决问题时更加有效。往好了说，这是对问题的天真定义，往坏了说，是有动机的推理。这造成的日常操作劳作的重量会把你压死。

对技术的慎重选择给了工程学头脑真正的自由：思考更大问题的自由。技术本身就是蛇油。

更新，2015年7月27日：我根据这篇文章写了一篇演讲。你可以在这里看到它。

Etsy早年曾深受其害。我们雇佣了一群Python程序员，并决定我们需要为他们找到在Python中可以做的事情，而脑海中唯一浮现的事情就是创建一个毫无意义的中间层，这需要多年的努力才能截断。与此同时，第90个百分位数的搜索延迟约为2分钟。Etsy并没有失败，但它已经好几年没有发货了。因此，它花了比需要的更长的时间才取得成功。

我们经常不经意地将厄运的无聊/糟糕交集称为“企业软件”，但这个术语可能并不准确。

拉姆斯菲尔德这样说，有意无意地暗示了苏格拉底悖论。所有人都说，苏格拉底在很多方面都是一个深思熟虑的人，而拉姆斯菲尔德不是。

根据我的经验，Etsy的活动提要就是一个很好的例子。当我们构建此功能时，我们非常努力地将Etsy的大部分整合到PHP、MySQL、memcached和Gearman(PHP作业服务器)上。在该堆栈上实现该功能要比使用Redis(也可能不是)要复杂得多。但是在该堆栈上构建活动提要是完全可能的。

这个项目发生了一件令人惊讶的事情：我们的注意力在几年内转移到了其他地方。在此期间，在根本没有人观看的情况下，活动馈送的规模扩大了20倍。我们没有专门针对活动提要进行任何更改，但由于我们使用的是一个共享平台，所以随着使用量的爆炸性增长，一切都进行得很好。简而言之，这是限制技术选择的长期好处。

这不是一个绝对主义立场--虽然存储在memcached中的活动提要被认为是实用的，但在原始PHP中使用分面实现全文搜索是不可行的，所以Etsy使用了Solr。