为 95% 而非 5% 优化编程决策

本文最初于 2018 年 11 月 26 日发布于： https: //nickjanetakis.com/blog/optimize-your-programming-decisions-for-the-95-percent-not-the-5-percent

几周前，我在 HackerNews 上看到一篇有趣的文章，标题是“我为什么编写 33 个 VSCode 扩展以及如何管理它们”。

这个标题确实吸引了我的注意力，所以我做了大多数人都会做的事，那就是在阅读文章之前直接查看评论。

我就是在那里发现了这条评论：

我的问题在于，添加插件或扩展环境超出默认设置后，最终不得不处理同事未扩展的默认安装。最终我过度依赖插件了。

读到这些我真的很受触动，因为很久以前我也是这么想的。

但后来我看到了这条评论：

我非常不喜欢这样的推理，即你应该 100% 地束缚自己，以适应可能在 5% 的时间内影响你的潜在情况。

“我不使用多台显示器，因为有时我只使用一台笔记本电脑”。

“我不自定义我的 shell，因为有时我必须通过 ssh 连接到服务器”

“我不会自定义我的编辑器，因为有时我必须使用同事的编辑器”。

我们来到这里是因为我认为这是一个非常被低估的话题。

“假设”条件

很多年前，我记得我避免使用 Bash 别名，因为你知道，如果我通过 ssh 进入服务器，它可能没有这些别名，那么我就完了！

我正在针对这 5% 优化我的开发环境，但它所做的只是让事情变得持续不断的斗争。

疯狂的是，当时我脑子里觉得这些话很有道理。说服自己同意上面列出的一些引言以及更多其他引言其实很容易。

但针对 5% 进行优化是针对“假设”情景进行优化的一个例子。

你尽一切努力确保你做的事情足够通用，可以在任何地方使用，但你真正做的是在 95% 的情况下让事情变得更困难，但 95% 才是最重要的。

它会影响你编写的代码

这不仅仅与开发环境决策有关，它还会影响你编写的代码。

如果您尝试从一开始就编写一些完全通用的东西，因为“如果我制作另一个应用程序并且它需要注册用户怎么办？”那么您通常会使您的初始实现变得更糟。

如果不深入理解自己正在开发的内容，并投入时间根据实际经验提出良好的抽象概念，那么你只是在盲目地希望你的通用用户系统能够适用于所有情况，而你甚至还没有针对一个用例进行编程。这怎么可能呢？

它影响你如何构建你的应用程序

当你盲目追随谷歌和其他大公司的做法时，你会以稍微不同的方式针对那 5% 进行优化。

您不只是启动并运行您的应用程序并观察其运行情况，而是尝试做出决策，以便您的应用程序能够由 100 个不同的团队（分布在 5,000 名开发人员）进行开发。

同时，在几乎所有新项目的情况下，您都需要自己开发应用程序。

它影响您​​部署应用程序的方式

当您尝试从第一天起优化部署策略以每秒处理十亿个请求时，您只是让自己陷入基于理论的研究的无休止循环。

它通常包括花费数月时间研究如何设置一个神秘而完美的自动修复、自动扩展、多数据中心 Kubernetes 集群，但它毫无结果，因为这些解决方案不够通用，无法适用于所有情况，而无需大量特定于应用程序的细节。

你有没有想过，为什么 Google、Netflix、GitHub 等公司只提供关于其部署基础设施的零碎信息？这是因为这样可以优化他们获得更好工具的机会。

有什么比让这些工具看起来尽可能有吸引力，然后用“我们用它每月提供 200 亿次页面浏览量，所以你知道它是有效的！”来支持它，更好的方法来吸引人们对他们的开源项目的兴趣并致力于此呢？

这确实是一个引人入胜的故事，但它绝不会像插入 Kubernetes 这样的工具并拥有一个完美的集群那样简单，该集群会按照您设想的方式运行，当涉及到您的应用程序时，一切都应该在您的脑海中运行。

看一个基于玩具示例的演示很容易，也很容易理解它的工作原理，但这只会让这个工具从外表看起来像天堂。这并非全部。

一旦你开始尝试让它为一个真正的应用程序工作，或者更具体地说，你的应用程序，它就会崩溃，直到你花时间真正了解扩展应用程序需要什么（这不仅仅是选择工具）。

创造这些工具的公司多年来投入了大量的时间并拥有了这些知识，但这些知识只针对它们的应用。

他们可能会利用特定的工具来简化流程，而 Kubernetes 等工具绝对有价值，但这些工具并不是故事的全部。

如果将您的应用程序放在一台每月 40 美元的 DigitalOcean 服务器上，您就可以实现零停机部署，每月处理 200 万次页面浏览量，成千上万的人使用您的应用程序，而这一切都无需费力 - 所有这些都不需要 Kubernetes 或尝试颠覆您的整个应用程序架构来使用“无服务器”技术？

我以前也做过以上所有事情

我在这篇文章中多次提到“你”，但我并不是专门针对你，也不是针对整个编程社区。

我做过与上面所写类似的事情，但是使用不同的工具并做出不同的决定，因为技术随着时间的推移而发生了变化。

我清楚地记得这一切在我脑海中发生转变的情景。那是大约 8 年前 Node 刚刚发布的时候。

我记得自己使用 PHP、编写应用程序、发布应用程序、从事自由职业等时相当开心。但后来我看了 Ryan Dhal 关于 Node（他创建了 Node）的演讲，然后我开始连续 6 个月沉迷其中。

诸如“我的天，事件循环！”，“我的天，网络规模！”，“后端和前端都用一种语言？闭嘴，拿我的钱去！”这样的想法现在整天在我脑海里盘旋。

所以我所做的就是阅读有关 Node 的知识，几乎没有编写任何代码，直到最后我开始编写代码，虽然我学到了很多关于编程模式的知识，并且作为一名开发人员的水平普遍有所提高，但我意识到 Node 的一切都并不重要。

这主要是因为后端和前端开发总是会有上下文切换，即使你对它们使用相同的语言，并且许多语言都有帮助并发的解决方案。

那六个月左右是我一生中最没效率、最不开心的日子。倒不是因为 JavaScript 有多烂，而是因为当你置身事外，什么都不做，脑子里总是想着“如果……会怎样”，那真的会很累。

我仍然很感激我经历了那个阶段，因为它确实开阔了我的眼界，彻底改变了我对一切事物的看法——甚至包括编程之外的东西。

过早优化是万恶之源

唐纳德·克努斯 (Donald Knuth) 在 1974 年写道：

过早的优化是万恶之源。

针对那 5% 进行优化是一种过早的优化。对于你的开发环境选择来说，可能并非如此，但对于其他情况来说，肯定如此。

你的决策应该以针对 95% 的优化为基础，保持简单，并观察其效果。换句话说，在真正需要时进行优化，而不是因为“如果……会怎样”。

您在哪些情况下针对这 5% 进行了优化？请在下方留言告诉我。