我是Dan McKinley。那就是我。这是一个隐喻。 #
我在一家名为Mailchimp或Mailkimp的公司工作,如果您收听播客。我是Etsy的早期雇员,这对我来说是一种成长性的经历,所以我会在那儿花很多时间。但是自那以后,我已经在其他几个地方工作过。 #
我曾在大型公司和小型公司以及自己的小型初创公司工作过。我注意到了几件事。大公司可以采用品牌方式进行工程设计。例如,做工程的“ Etsy Way”就变成了一件事情。生活在满足您的需求并回答问题的盒子里,可能会令您有点不适。但是我也一直在积极地寻找“完成工程的方式”或处于过渡时期的情况。在这种情况下,我不得不考虑几个问题。 #
首先,如何选择要用于完成工作的工具? #
我关心的另一个问题是:如何使开发人员满意?作为开发人员,这对我很重要。如果可能的话,我想开心。 #
如果您去找开发人员说:“嘿,什么会让您开心?”您通常会得到非常具体的答案。他们会说:“如果我能在工作中写Clojure,我会很高兴,所以你应该让我在Clojure中工作。”我不否认,当他们这样做时,开发人员确实是在描述他们曾经拥有过的某种富含内啡肽的经验。但是,我怀疑他们所描述的状态是精神修养的最高境界。 #
例如,早期的Etsy是PHP意粉的一大卖点。它是由某个在编写PHP时不幸学习PHP的人编写的。我花了几年时间试图避免与它打交道。有一次我尝试构建与MongoDB对话的Scala服务。我认为这将带来更好的基础架构,解决我所有的生产力问题,并使我感到高兴。但是事实证明事实并非如此。这个时期令人难堪的残骸仍在互联网上,您可以去找它并取笑我。 Etsy的员工仍然有充分理由给我这件事。 #
当我上一次拥有自己的创业公司时,我确实使用过Clojure。我不认为Clojure是原因,但在此我要声明创业公司不再营业。无论如何,我想提供这些轶事作为我的非轻浮的诚意。我不是从未经历过函数式编程乐趣的人。您不需要@我谈论Scala或Haskell。当然,即使我什至没有提到您或那些语言,史蒂夫也不必反驳将这一切都当做个人。 #
但是无论如何,尽管如此,我还是不是一个痴迷工具的工程师。我的其他谈话几乎没有涉及工程。 #
我不认为我会那样做是因为我变老了,胡思乱想。尽管我肯定是这些人,但我认为我可以通过在过去的某个时候登顶马斯洛的等级制度来对此有所了解。简而言之,马斯洛(Maslow)的等级观念是,您必须满足更基本的需求,然后才能实现更高的知识水平。如果您担心今天要吃什么,就不能做诗。 #
我们可以看一下齐格弗里德·沙宣(Siegfried Sassoon)的案子,并思考诗歌是否属于这种情况,但是我认为这在软件中基本上是正确的。如果您正在忙于使用哪个数据库或警报系统,则不必担心总体情况,也可以就产品的方向提出明智的问题。我很幸运能够满足这些基本需求。我想帮助其他人达到这种状态。 #
达到这种状态的重要一步是意识到注意力是宝贵的。人类具有有限的汗水细节能力。 #
我的朋友安德鲁每天都穿着相同品牌的黑色衬衫。他认为,如果他能节省脑力,那就可以选择要穿的衣服,他会把它存起来,以后再用于其他用途。我不知道这对时尚或您有什么意义,但我真的认为这有一定意义。 #
我喜欢这样考虑。假设我们所有人都可以使用数量有限的创新代币。这只是我虚构的,我的ICO下周开始发售。这些代表了我们有限的能力去做有创意的,奇怪的,艰苦的事情。我们真的没有太多要分配的东西。在公司生命的早期,我们大概只有三个人。仅此而已。 #
那么,您的公司想做什么?好吧,我以前工作过的Etsy曾经声称它试图重塑整个世界经济。现在,我不知道我们应该在多大程度上认真对待科技公司的使命。我开始怀疑我们根本不应该认真对待它们。但是,让我们过一会儿再考虑一下,如果他们真的想这样做的话,会带来什么影响。 #
重塑整个世界经济听起来是一项艰巨的任务。这可能至少要花费您的令牌之一。 #
我在Etsy之后工作的一家公司试图“增加互联网的GDP”。 #
同样,这听起来很复杂。我们可能必须为此花费至少一个令牌。也许两个。也许所有人! #
如果您将创新视为稀缺资源,那么走在数据库创新的最前线就变得没有意义了。或关于编程范例。关键不是这些东西行不通。当然可以。并且有许多实际起作用的例子。但是,存在时间更长的软件与刚发布的软件相比,往往需要更少的维护和投入。 #
为了找到原因,我想谈一点知识哲学。我们对某项技术有什么了解?这实际上不是一个无聊的问题。真的很重要#
我讨厌唐纳德·拉姆斯菲尔德,也希望他能炸。但是他与以下内容相关,这与我们的主题完全相关。所以我觉得我必须承认他的恶魔存在足够长的时间,以使自己与他保持距离。 #
当我们不知道某物时,实际上可以分为缺乏知识的两个不同类别。存在已知的未知数,即我们知道而我们不知道的东西。还有未知的未知事物,我们不知道,我们不知道,我们不知道的事情。 #
这适用于技术。这是一个已知未知数的示例。对于给定的数据库,我们可能不知道发生网络分区时会发生什么。但是我们知道可以进行网络分区。由于我们知道这是可能的,因此我们可以对此进行测试。或者,我们可以跨过手指,希望那不会发生。无论哪种方式,我们都会告知可能性。 #
技术上还有未知的未知数。这是我前一段时间看到的一个随机示例。这个人花了四个月的时间来弄清楚为什么他会出现GC暂停,事实证明这是因为他正在将统计信息写入文件。他不知道那是可能发生的事情,但是确实如此。软件中的许多错误都是这样。我们不知道他们在那儿,我们甚至都不知道我们应该在寻找他们。它们是未知的未知数。 #
现在,重要的是要意识到所有软件中都存在这两种类别。通常,已有10年历史的软件附带一个JIRA实例,里面有很多票证,描述了没人能修复的损坏的东西。然后,总会有没人知道的错误,即使是永远存在的软件也是如此。 #
但是说所有技术都是等效的是错误的。新技术对这两个集合都有较大的基数。新技术通常具有更多已知的未知数,还有更多未知数。这真的很重要。 #
对于该内容,我选择“无聊的技术”作为精妙的SEO友好标题,但我对此感到遗憾。这有点分心。 “无聊听起来很糟糕,他为什么说这很好呢?”等等。这是一个真正的狗屎秀。但是,我的目标并不是要像CSPAN那样无聊地“无聊”。我的意思是说,它很容易理解,很无聊。不好,但是你知道为什么不好。您可以列出所有会让您失望的主要方法。 #
所以,好的,您所要做的就是使用Postgres,您已经准备好了,对吧?好吧,不。不幸的是,您选择的事物的组合也很重要。 #
假设您已经在使用此堆栈。您有Python,Memcached,MySQL和Apache。 #
假设您有一个新的问题要解决。您认为将Ruby添加到现有堆栈中是否有意义? #
几乎每个人都带有任何调味料的直觉是“呃,天哪,也许不是。”我们知道,添加红宝石的边际效用不会超过我们添加它所带来的复杂性。 Python和Ruby基本相同。 #
好的,添加Redis怎么样?我们已经有MySQL和Memcached,但是我们应该添加Redis吗? #
以我的经验,车轮在这里脱落。人们丢下了粪便,开始殴打他们的多语言程序员鼓。关于添加一个新数据库的想法有些让人不寒而栗,他说:“伙计,您不能阻止我们使用最好的工具来工作。”当人们屈服于这种本能时,他们会告诉自己,他们在给开发人员自由。当然,这是自由,但这是对自由的狭义定义。 #
这就是我们想要添加一项半冗余技术时所隐含的说法。我们要说的是,这项新技术将在短期内使我们的工作变得更加轻松,以至于这项收益超过了无限期使用该技术的成本。 #
那不是很复杂的前提。我们可以尝试对其应用结构化思考。 #
备份一下,您的工作就是我的朋友Coda在这里说的。您应该使用技术来解决业务问题。 #
我们所处的领域据称与计算机科学有关,因此我们可以在这里假装自己是计算机科学家一分钟,并将这种情况建模为二部图。左边是业务问题,右边是技术解决方案。 #
我们必须尝试连接左侧的所有节点,以便解决我们的问题。在这里增加优势是一种技术选择。 #
每种选择都有维护成本,但我们也会从所选技术中受益。我们解决问题,我们都有能力解决其他问题,无论如何。 #
当我们添加多个边缘时,我们可以做出选择。我们可以使用已经支付的相同技术…#
或者,我们可以选择其他技术。我们也必须为这项新技术付费,但是也许我们获得了如此之高的开发速度或内啡肽,这是值得的。 #
我们正在尝试最小化此成本函数。我们的运营总成本是我们从选择中承担的所有维护成本,减去开发速度和从每个选择中获得的收益。 #
我们的行为方式实际上取决于您对在现实世界中哪个术语主导这个方程式的看法。如果技术的运营成本确实很高,则成本将占主导。如果技术确实在您的工作轻松程度方面产生了巨大的变化,那么收益将占主导地位。 #
因此,根据情况,您可能会决定进行这样的分配。在这里,我们选择了许多不同的技术来解决所有问题。 #
这是另一种策略。在这里,我们只选择了涵盖我们领域的一些技术,并通过这些技术解决了我们所有的问题。 #
如果我们认为所添加的每种技术都带来很多负担,那就是我们应该做的。 #
这是现实。永久性地使用一项技术的成本往往超过了使用其他方法所带来的便利。 #
因此,这往往是安排事情的正确方法。通常,我们应该选择覆盖问题领域的最小技术集,并让我们完成工作。 #
之所以如此,是因为要以专业水平操作一项技术真的很困难。大量的技术很容易上手,但是要真正做好它就很难。 #
这就是为什么。添加技术很容易,但要适应它很难。这些都是您需要担心的事情。我可以在进行此讨论的同时在此处立即酝酿安装一个新数据库,并开始向其中写入一些数据。上帝可以帮我,别让我这样做。但这完全是另一回事,要在专业水平上进行生产。 #
因此,多语种持久性不是我们所追求的那种自由,老实说,我希望马丁·福勒(Martin Fowler)早已将它付诸东流。如果您要让个人团队(或上帝帮助您,个人)自由支配权,以做出有关基础架构的本地决策,那么您就在全球范围内伤害自己。当然是自由的。您要给开发人员提供一连串的锁链和挂锁,并告诉他们随时将自己束缚在与他们同在的辛苦工作中,直到痛苦的甜蜜释放。 #
情况变得更糟。不仅要避免重复劳动,而且要避免过多的运营开销。通过拥抱多语种持久性,您还舍弃了只有在每个人都使用共享平台时才会产生的真正的积极收益。 #
我过去的一个很好的例子是Etsy的活动供稿。 Twitter是/曾经是一个活动供稿,Facebook的新闻同样也是。 Etsy花了很多年时间来筹集风险投资资金,巧合的是,我想也想要像他们一样的提要。我在2010年与一个小团队合作建立了这个程序。这非常有趣。 #
如果您要这样做的话,这是一种构建活动供稿的完全合理的方法。您从外界获得事件,然后将它们写入数据库。然后,出现了一个脱机流程并对其进行汇总,将一些机器学习知识投入到事物上,然后将物化的新闻源填充到诸如Redis之类的事物中,以服务于前端流量。这将完全正常。 #
但是,当我们着手建立活动提要时,我们没有Redis。我们确实有Memcached。从某种意义上说,它们有点相似,您可以在其中塞入一个Blob,然后使用相似的API将其删除。但是它们有非常不同的保证。与我们最相关的区别是Redis是持久的,Memcached是短暂的。 #
这意味着,如果要使用Memcached构建活动供稿,则必须做很多额外的工作。您必须应对Memcached在您需要的时候删除数据的可能性。在编写代码以交付功能时,这需要大量工作。但是我们权衡了使用新型数据库的持续成本,并决定坚持下去,并在Memcached上构建功能。 #
然后我们走开了。在那之后的几年里,我们没有做任何与活动提要相关的事情。我们几乎没有考虑过。 #
然后有一天我说:“嘿,我想知道活动的反馈是如何进行的。”我看着它,很惊讶地发现,自发布以来,使用量增加了20倍。据我所知,它完全可以使用。可能有2,000%的人在使用活动供稿,而我们甚至不知道它正在发生,这一事实无疑是我职业上最大的纯技术成就。 #
之所以可能,是因为我们使用了共享堆栈。有些人注意到我们需要更多的MySQL或Cron Box或其他工具。还有其他人必须去数据中心并插入新机器。但是他们之所以要进行横向扩展,是因为站点正在整体发展。没有人知道我们的独有功能。 #
如果我们仅将Redis部署为活动供稿,则可以确定,随着功能的扩展20倍,Redis一定会感到不安。而且我们不得不回过头来研究Redis,只是为了保持活动供稿正常工作。 #
或更可能是,其他人将不得不这样做。一年之后,我们的团队就不复存在了,我们都在从事不同的工作。我注意到的是,人们喜欢清理我的混乱甚至比清理自己的混乱还少。因此,这对于每个人来说都会变得尴尬而可怕。 #
因此,在这里我要说明的是,您应该倾向于偏爱成熟的事物,并且应该尽量不要使用过多的事物。但这不是绝对原则。显然,有时候将新技术添加到堆栈中确实很有意义。而且,使用怪异的新东西甚至可能很有意义。 #
因此,我想谈谈您可能如何做到这一点。 #
总而言之,就是你必须互相交谈。技术会对您的公司产生全球影响,这不是每个工程师都应该拥有的。您必须找出一种使添加技术成为对话的方法。如果您在这里期望有一个有洞察力的大秘密,那么这可能会令人难以理解,但是请相信我,这超出了许多技术组织的范围。 #
假设您通过对话成功保护了新技术。在这样的对话中,一个很好的第一个问题是:“我们如何在不增加任何新内容的情况下解决眼前的问题?” #
这是一个很好的问题,因为它可以立即确定问题所在,即我们想使用一项新技术。 “嗯,问题是我们不使用Cassandra,但也许可以。”那种事如果您确定这种情况,那就太好了,因为您可以立即停止谈论它。 #
但是无论如何,假设您遇到了实际问题,答案很少是您做不到。如果您已经拥有可以在生产中进行任何复杂性的功能性服务,并且认为您无法用已有的功能来完成一项特定的新功能,那么您可能就没有足够的思考力。您可能需要诉诸不自然的行为,但只要花最少的钱就可以走得很远。 #
真正写下您要做的所有尴尬事情真的很值得。很多时候,您会发现情况并没有那么糟糕。或者它可能很糟糕,但不如操作新事物的任务那么糟糕。但这也可以相反。您可以列出所有不自然的行为,并得出结论,添加新事物将是值得的。 #
而且,如果您决定尝试一项新技术,则应该找出低风险的入门方法。您的策略不应该一步一步地重写整个应用程序。您应该以最小的风险证明生产中的技术,然后逐渐对其充满信心。 #
如果您要添加一项多余的技术,那么您的目标就是用它来代替某些东西。您的目标不应该是永远操作两项相互冗余的技术。当您添加替换另一个事物的事物时,您应该致力于替换旧事物的计划。这可能是一个长期计划。如果新工具无法实际使用,那么您应该承诺使用旧工具重写新东西。 #
大多数时候,这是您应该做的。 首选具有众所周知的故障模式的众所周知的技术。 # 考虑一下您的整体工作,并选择一些涵盖整个问题领域的工具,并用它们解决所有问题。 ......