选择无聊的技术

多年来，我观察到许多工程师倾向于将公司的成败归因于所做出的技术选择。我知道我也经常为此感到内gui。尽管这通常是有道理的，但我想指出，对于绝大多数初创公司而言，编程语言，框架甚至数据库的选择都没有太大关系。在早期阶段尤其如此。

这种看法是可以理解的，作为工程师，我们倾向于从特定的角度看待世界，并且常常因我们最了解的事物而产生偏差。我们的日常活动可能包括诸如调试CI管道，实现新功能，与同事配对或迁移始终存在的旧代码库之类的事情。我们周围的环境使人们容易相信一切都归结为我们所看到和理解的那些事物。这是一种幻觉，使我们觉得自己完全控制着制造或破坏产品的原因。

别误会，对于许多公司来说，使产品的效率比竞争对手高3倍或拥有精美的可组合代码可能是一个巨大的优势。但是，如果没人在乎您实际生产的产品，那么您可能会把重点放在错误的问题上，而您的企业迟早会陷入困境。

我并不是说软件无关紧要。为您的创业公司打下坚实的基础。如果投资于此可以使您比竞争对手更快地构建更好的功能，则可以为您提供更多的功能。但是，找到合适的平衡高度取决于您要解决的问题和手头上的资源。这样做没有对与错的方法，通常，这主要取决于权衡。

我认为，要在技术选择方面实现风险与回报之间的健康平衡，这是值得我们努力的目标。尤其是，如果它减少了您在将来遇到错误问题的机会。

这就是为什么我开始欣赏“选择无聊技术”之类的想法的原因。通常将其解释为“将旧技术替代新技术”，但这并不一定意味着这一点。对我而言，这归结为使用行之有效的行之有效的技术，其中失败的方式广为人知，但偶尔尝试使用可能更适合我的其他（可能是较新的）工具。

也许您想通过使用最新的框架或编程语言来获得更多经验，或者您只是想找点乐子。你做使自己快乐的事情。但是，如果您要决定增加产品或业务成功的几率，那么就应该退一步考虑一下您的选择。

对我来说，主要是选择使用时间更长的软件，并不是说它很乏味或更旧，而是因为人们更了解失败的方式。您需要处理的未知数更少，这最大程度地增加了实际交付项目的机会。

例如，前几天我的Django应用出现问题，快速搜索使我在各种论坛和网站上都对这个问题有了数十个答案。我最多花了10分钟才恢复正轨，到此为止。

几年前，我遇到了一个与众不同但与众不同的，经过了实战测试的Scala库，而我的团队已经使用了一段时间。我们可能是最早遇到我们所面临问题的国家之一，似乎以前没有人走过这条路。也许这听起来像是一个有趣的挑战，或者是为OSS做出贡献的绝佳机会（我很乐意），但是一旦您解决了它，您的客户是否真的关心它？您愿意在这些问题上投资多少天，几周甚至几个月？就我而言，我宁愿利用这段时间发布新功能或改进现有功能。

当我选择工具时，我尝试遵循80/20的发行版。这意味着我的软件栈包含大约80％我已经很熟悉的软件，但是我确实允许自己20％的软件栈探索我经验较少的技术。确切的比例在这里并不重要，更多的是您应该倾向于使用经过验证的技术。

这也与多臂匪徒的工作方式产生了共鸣。您尝试通过利用过去有效的方法来最大化您的预期收益，同时有时会探索新事物，以避免错过可能的金矿。

我的一个最近的例子是Panelbear，它最初是一个令人尴尬的简单Django应用，没有图表，所有指标均在纯HTML表格上呈现，所有数据均存储在SQLite数据库中。从字面上看，它花了一个周末才能启动并运行，包括手动部署到$ 5 / mo的VM。当时我的需求低风险，高回报。

快进，随着我添加更多功能并开始处理各种网站的更多页面浏览量，我开始注意到代码库可以使用某些重构。诸如部署到新实例，发布SSL证书以及保持DNS记录最新以防我实例IP地址发生更改的事情也变得越来越重复。

作为第二次迭代，我升级到了docker-compose设置以及许多粘合代码。但是很快，我发现自己正在重新发明其他已经很好的工具。解决这些痛点的方法有多种，但就我而言，归结为使用我在全职工作中非常熟悉的工具Kubernetes。

是的，我很清楚，Kubernetes对于许多项目来说绝对是过高的，我本可以摆脱更传统的解决方案。但是，这使我极大地简化了操作方面，多年来，我很高兴为雇主减少了多次生产大火，因此我感到很自在。因此，我不会向所有人推荐它。尽您所知，另外一个好处是，当我从DigitalOcean迁移到Linode，最近一次迁移到AWS时，它也变得微不足道（每次迁移都花了一个晚上更改我的Terraform文件并部署它们-我是认真的）。但这是另一篇文章。

再次获得回报的另一种情况是，当我想尝试使用Clickhouse进行数据提取和聚合查询时。我花了不到10分钟的时间来编写一个基本的部署清单并使其启动并运行。这包括自动SSL证书，集群内服务发现以及开箱即用的统一日志记录/监视。这是一个巨大的胜利，因为它使我能够比以前更快地尝试事物。

更好的是，我可以部署任何容器并以与在集群上部署其他任何容器相同的方式操作它。需要零停机时间的更多卷存储？这是一个简单的清单更改，提交和部署。同样，当我需要Redis进行缓存时，我可以在几分钟内启动并运行，而不会增加成本或增加操作复杂性。

我的观点是，我进入这些技术是因为以前的解决方案所带来的痛苦大于应对新技术的痛苦。但更重要的是，它帮助我更快地将功能交付给客户，同时减少了我的运营开销。

如果从第一天开始使用更高级的设置，那么在拥有第一版Panelbear之前，我可能已经失去了所有动力。关键是要解决您与目标之间遇到的问题，而不是您相信一天将成为您的潜在问题。

希望您喜欢这篇博客文章。我计划撰写更多有关Panelbear技术栈的文章，并一路吸取教训。敬请期待！