看到新奇技术跃跃欲试？“无趣” 的技术往往更可靠

永远充满正能量

Being inspirational as always.

在离开 Etsy 以后，我对技术恢复了热情。我终于可以整理我的思绪并把之前所学的东西诉诸文字。如果 Kellan 发现我对他的思想体系了解的如此之深，也许会把他吓一跳吧。

拥抱 “无趣”

每个公司大概有三次为公司增加新技术的机会。你可以随时使用它，但是它用完即止。在公司发展成熟，业务逐渐稳定以后，你可能还会有几次机会，但是你最好对此抱有保守的预计。

每当你用 Node.JS 写网页，选择 MongoDB 作为你的数据库，或者使用存在不到一年的技术发现技术（Service Discovery Tech）时，你都在使用这一次次的机会。如果你还想自己写个数据库的话，天哪，你有麻烦了朋友。

如果你的公司从事 javascript 咨询服务或者数据库业务，这些决定都可能是明智的，但这样的情况很少。大部分的情况是，你的公司要完成的是 “重塑全球商业”、“重新发明网上支付” 之类看上去高大上的使命。在这样的情况下，用你有限的精力去改进 ssh 只会华丽的失败，或者你运气好的话，让成功迟一些到来。

但是，如何定义 “无趣” 却有些微妙。显然你不会去用那些既无趣又糟糕的技术，但是现在市面上仍然有很多 “无趣” 但靠谱的技术，比如 MySQL，比如 Postgres，比如 PHP，比如 Python，比如 Memecached，比如 Squid，比如 Cron。

那些 “无趣” 或者功能不够强大的技术的好处在于，它们所能做的事已经被很好地理解了，并且更重要的事，它们出错时，我们也知道如何补救。任何了解我的人都知道除非当前技术错误百出，我被搞得不堪重负时，我才会对其更新换代。

当你在选择技术时，有些不确定性你可能会有所预计，而有些你对此则毫无头绪。举个例子，当你的数据库 CPU 利用率达到 100%时，你知道它可能会发生一些问题，但是当你在写入数据的时候垃圾收集进程停止了？莫名其妙对吧！

全局优化

我是 “无趣” 技术的坚决拥护者，但是可靠性仅仅只是原因之一。每当你做出一项技术决定时，你的团队，你的公司架构，你的整个系统都会受到影响。

为你的公司增加新技术需要代价。显然，当你在使用 Ruby 的时候加进 Python 是不明智的，因为这么做所增加的复杂度会超过新技术所带来的边际效益。但是人们往往一提到 Python, Scala, MySQL 或者 Redis 便开始失去判断力，为了能在工作中使用最好的工具而对其负面因素视而不见。

作为一个技术管理人员，你的职责概括来说就是将商业问题映射到各类软件应用的解空间内。如果你没有任何负担，你的确在各个方面都选择你所了解到的最好工具。

当做出选择不需要付出高昂的代价时，道理很简单，选择你最顺手的工具。但是可以肯定的是，负担总是有的。我称其为 “运营负担” 或者额外的学习成本。我将会需要时不时的关注一下它，需要研究怎么进行单元测试，需要了解它的特性，需要自己写一个启动脚本······总会有事情会冒出来。

当运营成为一项重要因素的时候，你应该这样选择。

“在工作中使用最好的工具” 这一想法的最大问题是你对 “最好的” 和 “工作” 这两个词的看法。你的工作是让公司能够继续运转下去，而最好的工具能够在发生状况以后让你不至于为了解决问题而抓狂。

通常情况下，能够让系统可靠地运转远远比省力地搭建它要重要。成熟并且高效的开发者对此都深有体会。

当然，有时候我们也需要新技术

如果根据之前的原则一路走到黑，那就意味着选择了 Java 以后，就只用 Java 实现整个网站。下面是我的一些建议。

首先，你必须认识到你必须对增加新技术进行有效的沟通，并且不要期望能够一蹴而就。新的技术最后会对整个公司产生影响，所以你必须让全公司的人知道有这么一回事儿。你的公司可能要求你事无巨细一一汇报，也可能放手让你去做而不用跟别的部门打招呼，但是不管怎样，你必须让大家知道这是一个你一定会开诚布公的话题。

这里我建议你先想一想：你手头的工具是否足以解决你的问题？如果答案是 “是”，你很可能会发现真正的问题是某人实在是太想用新的技术了。这种情况下，你应该果断地放弃这一想法。

“我刚刚在网上研讨会上看到这个图数据库，我们应该试着用一下！”

当你发现很少的几个技术就能解决大部分的问题时，你也许会很惊讶。即使有一些看似无法解决的，也可能只是实现起来太复杂而已。所以当你觉得你无法用你现有的技术解决问题时，再想一想，也许会有创造性的解决办法。

当你发现解决问题的办法太困难成本太高时，一个有效的办法是写下每一个导致这一情况的直接原因。这跟前面的建议有点相似，但又有细微的差别。

新技术可能正好能填补你的技术空白（比如当你需要缓存系统，你可能会上 memecached），但是新技术也可能和你正在用的技术有所重合。如果情况是后面一种，你需要对此抱有明确的预期。划定好时间线，告诉所有人 “我们必须引进新技术”，这样你才能够将意外状况限制在可控制范围以内，并且避免为了优化你的解决方案短时间内引进各种新技术。

不过放心，这个过程不会让你头大，也不会引起论战，这只是你的一个课后作业。你只需要回答完每个问题，然后在会议里讨论它就行了。如果你想要增加新的技术或者在你的基础架构上增加新的服务，用这些问题考验你的想法，然后你的心里应该就有答案了。

想清楚就尽快开工吧

多语言编程的卖点就在于它能够让开发者随心所欲的选择工具解决他们的问题。但是事实真的是这样吗？这个想法不仅太傻太天真，并且十分的有误导性，因为你会发现你日复一日地为了让系统正常运行花费大量的时间。

所以说，明智的技术选择能够让你的工程师们有时间和自由去考虑那些更重要的问题，并且那些新技术所声称的好处并没有被证实。

1.Etsy 在早些年里深受其害。我们招了一大帮 Python 工程师然后决定要给他们找点事儿做。我们能想到的唯一一件事就是让他们写了一堆毫无意义的中间层，并且我们花了好多年我们才把这些玩意清理干净。与此同时，90%的搜索延迟仍然高达两分钟。Etsy 并没有因此失败，但是它在好多年以内毫无作为，并使它花了更多的时间得以成功。

2.我们常常把那些集无趣和糟糕于一身的东西叫做 “企业软件”，当然，我是开玩笑的。

3..Etsy 的活动订阅源可以很好地说明这一点。当我们尝试要增加这一特性时，我们花了很大的功夫去把 PHP,MySQL,Memcached，Gearman (一个 PHP 工作服务器) 和我们的系统整合在一起。但是和用 Redis 实现上面的特性相比（当然这依然可行），前者就显得简单多了。

这个项目之后运行的一直不错。我们的注意力在接下来几年里都在其他方面，而活动订阅源在这段时间内规模增加了 20 倍并且完全没有人去照看它。因为使用了共享平台，不管需求是什么我们都不用调整这个项目。这就是使用有限制性的技术能给你带来的长期好处。

当然，凡事都不是绝对的。活动订阅源中使用 memcached 是靠谱的，仅仅使用 PHP 实现全文搜索却不是，所以 Etsy 最后使用了 Solr。