开发者朋友们,我们该谈一谈这个问题了.你们应该知道本周的 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 团队的感受.现在,他们肯定宁愿自己去实现那个十一行的字符串填充函数.