前言

“快乐来自于推出产品”，喜欢这句。今日前端早读课文章由 @Chun-Fu Chao 翻译分享。

前端早读课：与你分享“我”的视界。

正文从这开始～～

嘿

我是 Dan McKinley。这是我在坑里的照片，这是某种暗喻。

我现在在 Mailchimp 工作，如果你有听 Podcast 可能会叫它 Mailkimp。我以前是 Etsy 的早期员工，我的观念在那里慢慢成形，所以我会提到很多在那发生的事。但我也在其他很多地方工作过。

我在大公司工作过、也在小公司工作过、还有我自己的小创业。过程中我注意到一些事。

大公司可以为自己的工程方法贴牌。像是 “Etsy 的工程方法” 成为了某种独自的东西。活在里面你的需求会被满足、也有人会回答你的问题，有时会宠坏人。

但我也遇过所谓的 “工程方法” 就只是一直在找出路，或是一直身处过渡期中。在这些时刻我想过几个问题。

首先，你要如何选用技术来完成工作？

另一个我关心的问题是：“要怎么让开发者快乐？” 我是开发者，觉得这个问题很重要。如果可以的话我希望快乐地工作。

如果你去找开发者问：“嘿，怎样你会比较快乐？”，通常会得到很特定的答案。像是：“如我能在上班的时候写 Clojure 就好了，你该让我在工作时用 Clojure 写程序。” 我不会无视他们说的话，他们真的在描述某种大脑充满脑内啡的体验。

可是我会怀疑他们描述的，是不是真的在心智的最佳状态。

但我也曾经是这样。

以 Etsy 为例，早期他是大一坨 PHP。是某个得边写边学 PHP 的可怜人的作品。

有好几年的时间我都在逃避它。直到某一天我尝试用 Scala 服务跟 MongoDB 来取而代之。我那时以为会改善 Infrastructure、解决我所有生产力问题、然后让我快乐。但最后事与愿违。

那段时期产出的破烂现在还在网络上运行，你可以去找看看然后来笑我。现职的 Etsy 员工不时会臭我，而这完全合情合理。

当我最后自行创业时，我选用了 Clojure。虽然我觉得 Clojure 不是罪魁祸首，但那个创业公司早就消失了。

我提这些故事是想说我不是一个反对任何新技术的人。也不是从来没有体验过写 Functional programming 的乐趣的人。

你不需要 @ 我来跟我争论 Scala 还是 Haskell。也不需要觉得像是被人身攻击需要反击，我都没有提到你还是那些语言啊，Steve。

即使讲了这么多，我大体上依然不是很执着于工具的工程师。我其他的演讲也很少提到软件工程。

我觉得不是因为老了变得易怒才会这样想。虽然我真的又老又爱生气，但我觉得有这观点是因为在过去某个时间点，我登上了马斯洛需求层次三角的顶点。

马斯洛需求层次，简单来说是你得先满足个人基础需求，才有可能追求更高层的心智实现。你没办法在担心下一餐没着落的时候写出诗来。

我们可以看看 Siegfried Sassoon 的故事，想想诗歌创作是不是这样。但我觉得软件工程应该是这样。在你忙着争论用什么资料库或是警报系统时，是没有办法明智地讨论产品的走向的。

我有幸待过基础需求都有被满足的情况。也想帮助其他人到达那种状态。

要达到那种状态最重要的一点是理解人的注意力很宝贵。

人类处理细节的能力是有限的。

我朋友 Andrew 每天都穿同样牌子的黑色衬衫。他觉得不用挑要穿什么可以节约他的脑力，省下来的可以用在其他事上。

我不知道以时尚角度来看是否合理，但我觉得有某些道理在。

我喜欢这样来思考。咱们假设我们只有有限的创新点数（Innovation token）可以花费。这个点数是我虚构出来的东西，然后我下周要 ICO 这玩意儿。

它代表我们对需要创意、诡异的、或是困难的事物的有限处理能力。我们真的没有多少点数好花。在公司草创期，可能大概就只有三个点数，不会多太多。

所以你的公司想做什么？我前东家 Etsy 说过想要重塑全世界的经济。

我现在不知道要多严肃地去看待公司宣称的使命，开始觉得我们不该当它一回事。

但先假设我们是天真如菜鸟，想想如果真的要达到这目的要怎么做。

重塑全世界的经济听起来像个大工程，大概至少会吃掉你一个创新点数。

我在 Etsy 之后的东家试图要：“增加网际网络的 GDP”。

这听起来也是个非常复杂的任务。也许我们该花一个创新点数、甚至两个、也许要三个 All-in。

如果你把创新当成是种稀缺的资源，那么把创新的精力放在资料库还是程序范式上就不太有道理了。

我不是说新东西动不起来。当然他们动得起来，也有许多成功运作的案例。

但是存在已久的软件通常比刚出炉的更不需要心力照顾。

要解释原因，我想谈一下有关知识的哲学。我们对某项技术能有多少了解？这很重要，不是无聊的问题。

我讨厌 Donald Rumsfeld，希望他下油锅。但他跟接下来要讲的理论息息相关，所以我觉得有必要提他有多坏，让我跟他保持点距离。

当我们不知道某件事物，实际上分为两种知识的缺乏。

有 “已知的未知”，我们知道我们不知道的东西。跟 “未知的未知”，我们连 “不知道” 本身都不知道的东西。

在技术上同理。举个已知的未知例子，对于某个资料库我们可能不知道它在网络分割（Network partition）时会有什么行为。但我们知道网络分割是有可能发生的。因为我们知道可能发生这个问题，可以动手去做测试，或是双手合十祈祷不会发生这种情况。总之我们知道有这种可能性存在。

技术也有未知的未知。这是我过去看到的某个案例。这个人花了四个月试图找出 GC pauses 的原因，结果是因为把 Stats 写档造成的。他完全不知道这样会有问题，但问题就是蹦出来了。

许多软件的 Bug 都像这样。我们根本不知道它的存在，也不知道要往哪边注意。这就是未知的未知。

重要的是所有软件都有这两种未知。用了十几年的软件应该会有个 JIRA 服务器里面放满 Ticket 写着什么东西坏了，但没人要修。然后还有至今仍没有人见过的 Bug，即使这软件已经被众人使用了许久。

但这不代表说所有技术都一样。新技术这两者基数都比较高。

新技术已知的未知较多，然后未知的未知多更多。这个差异很重要。

我用 “选择无聊的技术” 这个简单、SEO-friendly 的句子当作标题，现在我有些后悔。它有点误导人。人们会想：“无聊听起来蛮烂的，为什么他说是好事？” 之类的，情况变得很糟。

但我说的 “无聊的技术” 不是像看 C-SPAN 电视台那种无聊，我指的无聊是已经被充分了解的事物。他可能烂，但你知道烂在哪里。你能明确列出它可能让你失望的地方。

所以你的意思是资料库就选 Postgres 就对了，是吗？嗯，错了。不幸的是你选择出来的组合也有关系。

假设你已经选择了这个 Stack，有 Python、Memcached、MySQL、跟 Apache。

现在有个新问题要解决。你觉得把 Ruby 加入现有的 Stack 合理吗？

几乎每个有经验的人回答大概都是：“呃，天呀，不好吧。”

我们知道加入 Ruby 的边际效益不可能抵过它带来的复杂度成长。Ruby 跟 Python 基本上角色重复了。

好，那 Redis 呢？我们已经有 MySQL 跟 Memcached，还要加 Redis 进来吗？

在我的经验里，这种情况就会开始变得混乱。人们开始起邱，鼓吹要当多语言开发者。想加入新的资料库的人像是一群要冲进巴士底监狱的革命分子。喊着：“你不能阻止我们用最好的工具来开发！”

当人们屈服于这种躁动的本能，他们会说这是给开发者 “自由” 来圆。当然这是种自由，但是是一种很狭隘的定义。

我们到底在做什么？来深入探究一下。

当我们想加入一个有点冗余的技术，我们通常会说这个新技术带来的立即好处会超过未来持续维护它的成本。

这个假说的前提没有很复杂，我们可以以结构化思考去想它。

拉回来一点，你的工作像是我的朋友 Coda 说的，应该是用技术解决商业问题。

我们的领域跟电脑科学有点关係，可以假装我们是电脑科学家一下，用二分图来描述这种情况。

左边是商业问题，右边是技术方案。

我们要试着把左边的点都连到右边某点，代表我们的商业问题都解决了。加上一条边就代表是一个技术的抉择。

每个选择都有维护成本，但我们也会受益于我们所选的技术。我们解决问题，然后有能力解决更多问题，大致这样。

所以我们每个选择都有好处也有成本。

当我们要加额外的边时，我们可以选择用已经支付了成本的技术…

或是我们可以选别的技术。得支付新技术相应的成本，但也许得到的开发速率提升或是什么脑内啡是值得的。

我们在尝试儘量缩减开发成本。总营运成本是你所有选择的技术的维护成本加总，减去开发速率诸如此类的好处。

我们的行为跟你相信公式里哪个变数在现实中比较大有关。

如果技术操作成本高，就是成本主导。如果技术真的大幅改善了你的工作效率，那就是效益主导。

根据情况，你可能选择这样的配置。我们为了解决所有问题挑选了许多不同的技术。

如果额外的技术本身成本不高，这样做是完全合理的。

这是另一种做法。我们只选少量的技术来涵盖我们的问题领域、解决所有问题。

当加入技术带来的包袱很大的时候，这是我们该採取的策略。

现实中，新的技术都会伴随着巨大的包袱。

这就是现实，持续地操作某项新技术的成本总是会超过用新东西带来的方便。

通常这样才是对的。我们应该用最小的技术集合来涵盖我们的问题领域，把工作完成。

因为要达到以专业水准操作某项技术实际上很难。很多技术起个头容易，但是要做到出色很困难。

加入新技术简单，跟它长久相处下去很难。这些都是你要考虑的事。

我能现在一边演讲一边用 Homebrew 装个资料库，然后写些资料进去。我做得到，但是不要逼我去做。这跟在 Production 环境下专业地操作是完全两回事。

因此 Polyglot persistence（使用不同资料库储存不同资料）不是我们该寻求的自由，我真心希望 Martin Fowler 把他那篇该死的 Polyglot persistence 文章下架。

如果你让个别团队、或是个人自由地做局部的 Infrastructure 决策，以全局来看你是在伤害自己。

这是种自由没错，你等于是把脚鍊跟扣锁交给开发者们，说你们可以自由地把自己绑在营运的痛苦上。直到专案终止。

除了避免重工跟过多的操作成本，更糟的是因为 Polyglot persistence，你捨弃掉了所有人都在相同平台上才会出现的好处。

从我的过往找到的好例子是 Etsy 的 Activity feeds。

Twitter 是／曾是一个 Activity feeds，Facebook 的动态消息也是。Etsy 许多年来都在花 VC 的资金，我猜碰巧他们也想要一个像 Twitter 还是 Facebook 的 Activity feeds。

我跟一个小团队在 2010 开发了这个东西，过程还蛮有趣的。

如果你尝试建构 Activity feeds，合理的做法是：你从外在世界收到事件，把它们写进资料库。然后有些离线的程序会聚合（Aggregate）这些资料，再撒上一些机械学习魔法，将生成的 Activity feeds 放进 Redis 之类的东西送给前端。这样就会动起来。

但我们要开发 Activity feeds 时，没有 Redis 只有 Memcached。它们 API 都有点像是塞一坨 Blob 跟取出一坨 Blob，但它们做的保证相当不同。对我们最重要的差异在 Redis 有持久性（Persistent），而 Memcached 没有持久性。

实际上的问题在你想要用 Memcached 建构 Activity feeds，你有很多额外的工作要做。你得处理 Memcached 丢掉你想当下想要的资料的问题。

要这样完成这个功能需要一堆额外的工作。但是我们衡量持续维护新资料库的成本过后，决定牙一咬用 Memcached 建构这个功能。

然后我们就去做别的事了，好几年没再碰过这个 Activity feeds。甚至连想都很少想到它。

有天我想说：“嘿，我有点好奇 Activity feeds 现在怎样了？” 惊讶地发现从发佈到当时，使用率提高了二十倍。而且以我的认知，它运作起来完全正常。

我觉得多了 2000% 的人在用 Activity feeds，然后我们根本没有发现到，是我职涯中最大的技术成就。

原因是因为我们用了共同的 Stack。有些负责处理 MySQL 跟 cron 机器的同事注意到我们需要更多资源，然后有人去资料中心接上更多台电脑。因为网站是全面地成长，所以它们做的是水平扩充（Horizontal scaling）。过程中没有人注意到我们那个没没无闻的功能。

如果我们只为了 Activity feeds 部属 Redis，你可以想见某个时间点当需求成长二十倍时 Redis 会出大事。我们得要放下手边工作回去自己处理 Redis 让 Activity feeds 回复正常。

更可能的是，某个倒楣鬼要替我们做。我们的团队一年后就解散了，各奔东西。

我知道大家宁可擦自己的屁股，也不想帮我擦我的屁股。所以如果真的发生 Redis 的问题的话会让大家感到有点尴尬。

我提这个故事是想说你应该偏好成熟的东西，然后尽量不要用太多东西。

但这不是一个绝对的原则。显然有时加新技术到你的 Stack 是合理的，甚至有时用又新又怪的东西也可能是合理的。

所以我想谈一下遇到这种状况该怎么下手。

总而言之还是回到沟通

技术对你的公司有着全面的影响，这不是该让个别工程师决定的事。你要用沟通找出加入新技术的方法。

你可能觉得这个答案蛮老调重弹的，但相信我，很多组织都还是做不到这一点。

假设你成功地透过沟通将一款新技术拉回到要先讨论再看要不要加入。

第一个好问题是：“如果我们要解决这个问题而不用新技术要怎么做？”

这是个好问题，因为我们能立刻抓到想要用新技术槌子解决问题钉子的情境。像是：“呃，问题在我们没有 Cassandra，也许我们该用。” 这种回答。如果你发现这种情况，讨论大致上就可以打住了。

假设你遇到一个很难的问题，问题鲜少是你做不到。如果你有个已经在 Production 环境的复杂服务，然后你觉得某个特定问题非得引入新技术，我觉得问题可能是你想得不够用力。

你可能要在旧环境上做些不太自然的事，但是你其实能在最小的 Stack 上走很远很久。

列下用既有技术在旧环境上要做什么不自然的事以达成目标会很有帮助。很多时候你条列了，会发现事情其实没有那么糟。或者是跟维护新东西比起来还是比较好。

也有可能真的是採用新技术比较好，这样你也有证实这个结论的参考。

如果你要採用新技术，应该要尽量用低风险的方式开始。你的策略不该是一步登天地把整个应用一次改写完。你应该在 Production 环境用最低风险的方式证实其价值，然后渐渐取得大家的信心。

如果你要加入的是会造成冗馀的技术，你的最终目标该是替换到没有冗馀，不应该同时操作两个相互冗馀的技术下去。

当你加入一个东西取代原有的东西，你应该坚持把旧东西彻底拿掉。这也许会是个长远的计画。如果新的工具最终证实没有用，那也要把所有新的程序用旧的工具重写。

现在来做个收尾。

你该使用已经被实证的技术。用被充分了解，包括失效模式（Failure mode）也都被探索过的技术。

优先考虑使用让你能专注在真正问题的东西。

以大局来思考技术选择，解决整个问题领域的工具越少越好。

有趣的是，你选出来的工具可能都不是对个别问题 “最适合” 的选择。但还是有可能是对所有问题来说正确的 “一组” 选择。

彻底掌握你所选择的工具很重要。

我注意到所有工具都遵循以下的法则：当你刚开始用，你觉得糟透了，因为你看到一堆问题。

如果你天真地把新东西放进 Production 环境，亲身经历过这个法则，然后决定下个功能该用不同的东西来写。

这样下去你有一天从恶梦中惊醒，会发现你的 Production 环境有九个警报系统。

新东西不会更好，只是你还没有熟悉它所有糟糕的地方而已。

如果你这样下去就会错过曲线上我们称之为 “精通” 的部分，是这张曲线图靠右的状态。虽然还是有些问题，用起来感觉依然糟但还在可控范围内。

软件工程的残酷悖论是你可能该用你最讨厌的工具。因为你会恨它是来自于你最了解它。

当要加新技术到 Stack 时，应该要有个与人沟通的流程。

你应该尝试爬到马斯洛需求层次上面，烦恼整体大方向。不应该工作时天天在战该用哪个资料库。如果你真的天天在战，试着想想是不是有什么地方已经走偏了。

快乐来自于推出产品、功能。

关于本文
译者：@Chun-Fu Chao
译文：https://boringtechnology.club/index_zh_TW.html
作者：@Scott Ananian
原文：https://boringtechnology.club/
文字版：https://mcfunley.com/choose-boring-technology

这期前端早读课
对你有帮助，帮” 赞 “一下，
期待下一期，帮” 在看” 一下 。