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

NPM 代码复用| 2016-04-06

开发者朋友们，我们该谈一谈这个问题了。你们应该知道本周的 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，你又不懂得如何真正「编程」，你就无法解决问题。