“不要重新发明轮子”的隐性成本

在过去的几年里，我从最有经验的网络工程师那里听到过这样一句话。

不要重新发明轮子

大多数时候，当我听到“不要重新发明轮子”这个论点时，听起来像是出于一种舒适感。工程师们乐于使用现有的工具，即使它会导致系统臃肿、架构糟糕，或者可能导致最终用户体验不佳。当工程师为了自身利益做出决策时，真正的受害者是用户。

也许工程师对某个框架投入了大量精力，不想学习新东西。问题可能更具系统性。也许你的公司已经好几年没换过同一个技术栈了。这些障碍更难克服。

当你需要实现一个新功能时，通常开源社区已经提供了解决方案。这似乎是个无需思考的问题。使用工具吧。在从库中下架之前，你应该考虑一些事情。

学习曲线

当你采用开源工具时，你通常不知道自己会得到什么。README 会重点介绍你将获得的所有精彩功能。

安装软件包是第一步。你一步步按照 README 中的说明操作，直到遇到代码无法运行的问题。你查找文档，但那里根本找不到。你用 Google 查找，但什么也没找到。你翻遍了 Github 上的问题，却一无所获。最后，你决定查看源代码来排查问题。你对这种代码风格很陌生。单步执行代码后，你发现它已经被优化了。

永远不要低估学习新工具所需的时间。有时，你需要一段时间才能完全理解使用开源软件包的影响。你可能会遇到意想不到的障碍。

定制可能很困难

即使 npm 软件包能够出色地完成工作，该工具的某些部分也可能与公司的业务逻辑或设计模式不符。分叉一个开源项目或许是一个选择，但谁愿意维护它呢？你可能认为团队需要的功能可以贡献回开源项目，但有时这种贡献可能会遭到反对。

很多时候，工程师们使用开源工具来实现UI，以为这样能以某种方式加快开发速度。这可能意味着使用图表库或引导程序。我曾听到工程师们说：“如果不符合设计风格指南，那真是倒霉，我们得在这个Sprint中推出一个功能。” 这可不是什么好事。作为工程师，我们应该与设计和用户体验专业人士合作，为最终用户实现解决方案。购买而不是自行开发的决定可能会以牺牲协作为代价。工具可以加快交付速度，但当你不得不解释你没有听取设计和用户体验的意见时，在领导面前会是什么样子？

创新受到抑制

过度使用开源工具也带来了另一个代价。我们正在扼杀创新。当几乎每个人都在学习最热门的新 JavaScript 库而不是基础知识时，我们失去了从头开始构建所需的技能。我们失去了与语言本身的联系，因为我们总是与一个抽象概念——JavaScript 框架——交互。整个行业都被这些库的模式所束缚。我们拥有整个计算机科学的历史可以借鉴，也有机会设计新的模式，但我听到的却只有“redux”。

我们中的一些人时不时地会探出头来说“我们可以做些不同的事情”，但我们其他人听到他们的信息了吗？

膨胀

将库与应用程序捆绑在一起的一个更明显的代价是导致程序臃肿。一些第三方库无法进行树形优化。您无法只提取库中需要使用的部分。相反，您必须将整个库与应用程序捆绑在一起。

依赖项越多，打包文件越大，最终用户下载 JavaScript 所需的时间就越长。这对于占全球流量约 50% 的移动用户来说尤其重要。自主开发的解决方案很可能意味着更少的代码和更轻量的打包文件。

结论

“不要重新发明轮子”这句话我多年来听过无数次。有人告诉我，如果有一个库，就用它。然后我还是会去实现一个定制的解决方案。结果通常意味着更少的代码，针对特定的业务逻辑进行定制。我写文档，所以学习曲线很浅。构建和实现定制解决方案的意愿，可能是高级工程师和初级工程师，甚至首席工程师和高级工程师之间的一个关键区别。

过去几年，浏览器 API 不断发展。浏览器中内置了一些 JavaScript 库忽略的工具。随着主流浏览器的普及，我们是时候更多地使用这些 API 了。

去年，我在编写Readymade时，使用 ES2015 Proxy 以极少的代码实现了单向数据绑定。该库通过使用 BroadcastChannel API 来处理事件，从而克服了 DOM 事件的限制。一个用于生成 Readymade 组件的“hello world”代码大约 1KB（gzip 压缩后）。在实现所有 Readymade 功能后，包会略大一些。这只是原生 JavaScript 和浏览器 API 如何缩减包大小的一个例子。如果没有自定义解决方案，我将几乎没有其他选择来进行自定义元素开发，而且不会生成更多库代码。这样一来，我就无法定义开发者体验，也无法让 API 易于使用。

我现在就能听到了。“你为什么不使用 Svelte？”

我相信，如果行业中有更多的人花时间学习浏览器 API 和 JavaScript，我们就能进一步推动创新。与其把所有精力都花在掌握库上，不如想想如何实现一个没有依赖项的库。或许最终的结果会更轻量、更快速、更易用。