选择无聊的技术（2015）

# 选择无聊的技术 来源：https://mcfunley.com/choose-boring-technology 在我的职业生涯中，发生过的最好的事情大概就是让Kellan (http://laughingmeme.org/) 来负责管我。我跟了他足够久，看到Kellan的技术决策开始结出果实。我*从*中学到了很多，但也正因为这件事，我*作为结果*学到了很多。如果Kellan没有在那里如此彻底地把技术选择落到实处，我可能不会自由地成为写出《Data Driven Products Now!》(https://mcfunley.com/data-driven-products-lean-startup-2014) 的那个工程师。 一如既往地鼓舞人心。离开Etsy后的一年里，我重新恢复了对技术的关心能力。我的想法也结晶到可以连贯写下来的程度。接下来是对Kellan整体理念的提炼，希望只会让他稍稍惊恐。 ##### 拥抱无聊。 假设每家公司大约有三张创新代币。你可以随意花这些代币，但在很长一段时间内供应是固定的。在你达到一定程度的稳定和成熟之后 (http://rc3.org/2015/03/24/the-pleasure-of-building-big-things/)，你可能会得到更多，但总体趋势是高估自己钱包里的内容。显然这个模型是近似的，但我认为它是有帮助的。 如果你选择用NodeJS写你的网站，你刚刚花掉了一张创新代币。如果你选择使用MongoDB (https://mcfunley.com/why-mongodb-never-worked-out-at-etsy)，你刚刚花掉了一张创新代币。如果你选择使用存在不超过一年的服务发现技术 (https://consul.io/)，你刚刚花掉了一张创新代币。如果你选择自己写数据库，哦天哪，你有麻烦了。 如果你是一家JavaScript咨询公司或数据库公司，这些选择中的任何一个都可能是明智的。但你很可能不是。你很可能在一家至少表面上是重新思考全球商业 (https://www.etsy.com/) 或重塑网络支付 (https://stripe.com/) 或追求其他某种史诗级使命的公司工作。在这种情况下，把有限注意力投入到创新ssh上，是极好的失败方式。或者充其量，是延迟成功[1]。 什么算无聊？这有点棘手。“无聊”不应与“糟糕”混为一谈。有些技术既无聊又糟糕[2]。你不应该使用任何那些。但有很多技术选择是无聊且好的，或者至少足够好。MySQL是无聊的。Postgres是无聊的。PHP是无聊的。Python是无聊的。Memcached是无聊的。Squid是无聊的。Cron是无聊的。 无聊（如此受限）的好处在于，这些东西的能力被充分理解。但更重要的是，它们的故障模式被充分理解。任何了解我的人都会明白，我现在提起唐·拉姆斯菲尔德的幽灵，是带着一种极度不适感，但我必须这样做。 要说清楚，去他妈的这家伙。在选择技术时，你既面临已知的未知，也面临未知的未知[3]。 - 已知的未知是这样的：*我们不知道当这个数据库达到100% CPU时会发生什么。* - 未知的未知是这样的：*天哪，我们甚至没想到写统计数据会导致GC暂停 (http://www.evanjones.ca/jvm-mmap-pause.html)。* 这两组通常都不是空的，即使是已经存在几十年的技术也是如此。但对于闪亮的新技术，未知的未知的规模要大得多，这一点很重要。 ##### 全局优化。 我毫不抱歉地认为，偏向无聊的技术是件好事，但这不是唯一需要考虑的因素。技术选择不会孤立地发生。它们的范围触及你的整个团队、组织，以及由你所有选择总和所浮现出的系统。 给公司增加技术是有成本的。作为一个抽象的陈述，这很明显：如果我们已经在使用Ruby，再混入Python感觉不太明智，因为由此产生的复杂性会超过Python的边际效用。但不知为何，当我们谈论Python和Scala或MySQL和Redis时，人们就失去理智 (http://martinfowler.com/bliki/PolyglotPersistence.html)，丢弃所有约束，开始狂热宣扬为工作使用最佳工具。 你的职责简而言之 (https://twitter.com/coda/status/580531932393504768) 是把业务问题映射到涉及软件选择的解决方案空间。如果软件选择真的没有包袱，你确实可以为你的各种问题挑选一大堆局部最佳工具。 疯狂 Created with Sketch. 问题 技术解决方案 在选择成本低廉的世界里，你可能会这样选择技术：“为工作挑选正确的工具。” 但当然，包袱是存在的。我们把这个包袱称为“运维”，以及在较小程度上称为“认知开销”。你必须监控那个东西。你必须搞定单元测试。你需要对它有所了解才能修改它。你需要一个init脚本。我可以在这里说上几天，所有这些都会迅速累积。 理智 Created with Sketch. 问题 技术解决方案 在运维是严肃问题的世界里（即“现实”），你选择技术的方式。 “为工作选择最佳工具”这种想法的问题在于，它对“最佳”和“工作”这两个词持一种狭隘的观点。你的工作是让公司维持经营，该死的。而“最佳”工具是那个在尽可能多的你的问题中占据“最不坏”位置的工具。 基本上总是如此：保持系统可靠运行的长期成本，远远超过你在构建它时遇到的任何不便。成熟且高效的开发者明白这一点。 ##### 有时候，选择新技术。 把这个推理推向*归谬法*的极致，就意味着选择Java，然后尝试完全不使用任何其他东西来实现一个网站。那太疯狂了。你需要某种方式向工具箱中添加东西。 一个重要的第一步是承认这是一个过程，也是一场对话。新技术最终会有全公司范围的影响，所以添加技术是一个需要全公司可见性的决策。你的组织具体情况可能会迫使对话进行，或者它们可能会让开发者在不与任何人沟通的情况下添加新数据库和队列 (https://twitter.com/mcfunley/status/578603932949164032)。无论如何，你必须设定文化期望：**这是我们都应该讨论的事情**。 我在这里推荐的最有价值的练习之一是**考虑如何在不添加任何新东西的情况下解决眼前的问题**。首先，提出这个问题应该能检测出“问题”其实是有人真的很想使用这项技术。如果是这样，你应该立即停止。 我刚看了一个关于这个图数据库的网络研讨会，我们应该试一试。 一小套技术选择能走多远，可能会令人惊讶。这个问题在实践中几乎从来不是“我们做不到”，而通常只是在“嗯，我们能做到，但太难了”这个谱系上的某个位置[4]。如果你认为用现有的东西无法实现你的目标，那你可能只是创意不够。 有帮助的是**准确写下当前技术栈中到底是什么让解决问题变得极其昂贵和困难。**这与前面的练习相关，但略有不同。 新的技术选择可能是纯增量的（例如：“我们还没有缓存，所以让我们添加memcached”）。但它们也可能与你已经在使用的东西重叠或替换它们。如果是这样，你应该**为将旧功能迁移到新系统设定明确的期望。**政策通常应该是“我们承诺迁移”，并附上建议的时间表。这一步的目的是把烂摊子保持在可控水平，并避免局部最优解决方案的扩散。 这个过程并不可怕，也不麻烦。它就是几个问题作为作业填写，然后开个会讨论。我认为，如果一项新技术（或者要在你基础设施上创建的新服务）能毫发无损地通过这道考验，那么添加它是可以的。 ##### 只管发布。 多语言编程的卖点是，让开发者完全自由地选择自己的工具，会让他们更有效地解决问题。这充其量是对问题的天真定义，最坏情况下是