NPM 与 left-pad 事件：我们是不是早已忘记该如何好好地编程？

Posted 2020-07-05 福娃

转自：http://www.techug.com/npm-left-pad-have-we-forgotten-how-to-program

开发者朋友们，我们该谈一谈这个问题了。你们应该知道本周的 left-pad 事件： React 、 Babel 和许多流行的npm模块都受到波及，无法正常运行。

这一事件的起因十分令人诧异。

这些受到影响的模块都引入了一个叫做 left-pad 的模块。截至此时， left-pad 这个模块在Github上也只有寥寥十一个star。在整个模块中，作者只用十一行代码实现了一个简单的字符串处理函数。

以下就是这十一行代码：

module.exports = leftpad;
function leftpad (str, len, ch) {
  str = String(str);
  var i = -1;
  if (!ch && ch !== 0) ch = ‘ ‘;
  len = len - str.length;
  while (++i < len) {
    str = ch + str;
  }
  return str;
}

让我感到有意思的是，社区中许多的模块都选择引入这个十一行的模块，而不是花上两分钟的时间自己去实现这个简单的字符串填充功能。

事件发生之后，我开始仔细研究npm生态系统。以下是一些有趣的发现：

• npm上有个叫做 isArray 的模块。今天一天之内，它就被下载了八十八万份；光是今年二月，它就被下载了接近一千八百万份。模块本身只有一行代码： return toString.call(arr) == ‘[object Array]‘
• 还有一个模块叫做 is-positive-integer 。这个只有四行代码的小模块，竟然还要依赖另外三个模块。事件之后作者把那三个依赖去掉了；但我还是弄不明白作者为什么不早这样做。
• 装一次 babel 模块就要引入四万一千多个文件。
• 随便一个以 npm/jspm 为核心的项目模板就要引入超过两万八千个文件。

以上这些事实让我觉得，

我们是不是早已忘记该如何好好地编程？

这种过度依赖其他npm模块的做法是不是解决问题的正确方式呢？现在，一个空白项目模板一装好就要引入两万八千多个文件、依赖成百上千个其他的npm模块。这太疯狂了、而且过度复杂。

我觉得npm生态系统中，开发者有一种不良的、对微型模块的热衷。相对于自己实现一些小函数，开发者们更愿意去依赖其他人写好的模块。我甚至觉得npm生态系统中的开发者只想尽可能地少写代码，大量引入别人写的模块，拼拼凑凑、串起来交差。

一个函数并不能被称为模块

函数本身太小了，不应该被做成一个模块并被别的项目引入。一个函数本身并没有什么整体意义，只是随便一小段代码而已。假如我们现在要求一个角度的余弦值。 我们肯定不会专门为求余弦值引入一个「cosine」模块。如果要算cosine的值，我们更想要一个功能完整、带有其他三角函数的「三角」模块。 .NET 与其他许多框架都选择提供这样一个功能统一又完整的「核心」模块。大部分语言的设计者都会很仔细地编写语言自带的「核心模块」：这部分基本上是很安全没有bug的。

第三方依赖带来的问题

首先，没有人能肯定别人写的依赖是不是完全正确的。也许它们都不能正常工作。退一步说，就算这些东西都写对了，它们的实现就是最高效的吗？如果你选择不用依赖自己去写，你至少可以自己fix你能看到的问题、还能去尝试把它写得更高效。这不只是依赖写得对不对的问题。

其次，就算这些模块的逻辑正确也十分高效，我还是感到十分吃惊：开发者们竟然懒得自己写这些一两行就能实现的功能，选择去依赖别人写的模块；这些功能明明闭着眼睛都能写对。在我看来，如果你连上面提到的 left-pad 、 is-positive-integer 或者 isArray 都不能五分钟内边搜索边调试着写完，你其实根本就不会写代码。哎，这些小功能真应该被当作面试题：写不出来的话，只能说候选人不会写代码。

最后，我觉得把这些API串到一起、拿别人的模块七拼八凑的做法根本就不叫编程。这只不过是某种七拼八凑、过度设计、把事情复杂化的行为。

更糟糕的是，如果你的代码或者你引入的代码出了问题或者有些bug，你又不懂得如何真正「编程」，你就无法解决问题。

我们应该尽可能减少依赖的模块

每个你依赖的模块都会引入其他的模块。这些依赖，顾名思义，是一些你不得不需要的东西。你越多地依赖别人的模块，你的项目就会有越多崩溃的隐患。同时，你的项目出错的机率更大：你根本就不知道这些第三方模块的作者是否靠谱。

只有在遇到非常复杂，自己解决起来需要花很多时间、金钱的问题时才应该考虑依赖其他模块。比如，当需要一个数据库中间件（ORM）或者一个做客户 端缓存的组件时，你应该选择引入一个依赖而不是自己去写，因为这些活儿太耗时、太复杂了。引入这些组件可以省下很多时间；相比之下，它们出问题的风险也变 得可以接受。

但是除此之外，就算是因为对「编程」这件事的执念，你都应该去写这些基本的小函数。为了一个一两行就能实现的功能多引入一个依赖是一件很蠢的事情。你不信么？尽管想想 left-pad 事件之后React 团队的感受。现在，他们肯定宁愿自己去实现那个十一行的字符串填充函数。