NPM 与 left-pad 事件:我们是不是早已忘记该如何好好地编程?
2016-04-06 09:18
405 查看
转自:http://www.techug.com/npm-left-pad-have-we-forgotten-how-to-program
开发者朋友们,我们该谈一谈这个问题了。你们应该知道本周的
这一事件的起因十分令人诧异。
这些受到影响的模块都引入了一个叫做
以下就是这十一行代码:
让我感到有意思的是,社区中许多的模块都选择引入这个十一行的模块,而不是花上两分钟的时间自己去实现这个简单的字符串填充功能。
事件发生之后,我开始仔细研究npm生态系统。以下是一些有趣的发现:
npm上有个叫做
还有一个模块叫做
装一次
随便一个以
以上这些事实让我觉得,
我觉得npm生态系统中,开发者有一种不良的、对微型模块的热衷。相对于自己实现一些小函数,开发者们更愿意去依赖其他人写好的模块。我甚至觉得npm生态系统中的开发者只想尽可能地少写代码,大量引入别人写的模块,拼拼凑凑、串起来交差。
其次,就算这些模块的逻辑正确也十分高效,我还是感到十分吃惊:开发者们竟然懒得自己写这些一两行就能实现的功能,选择去依赖别人写的模块;这些功能明明闭着眼睛都能写对。在我看来,如果你连上面提到的
最后,我觉得把这些API串到一起、拿别人的模块七拼八凑的做法根本就不叫编程。这只不过是某种七拼八凑、过度设计、把事情复杂化的行为。
更糟糕的是,如果你的代码或者你引入的代码出了问题或者有些bug,你又不懂得如何真正「编程」,你就无法解决问题。
只有在遇到非常复杂,自己解决起来需要花很多时间、金钱的问题时才应该考虑依赖其他模块。比如,当需要一个数据库中间件(ORM)或者一个做客户 端缓存的组件时,你应该选择引入一个依赖而不是自己去写,因为这些活儿太耗时、太复杂了。引入这些组件可以省下很多时间;相比之下,它们出问题的风险也变 得可以接受。
但是除此之外,就算是因为对「编程」这件事的执念,你都应该去写这些基本的小函数。为了一个一两行就能实现的功能多引入一个依赖是一件很蠢的事情。你不信么?尽管想想
开发者朋友们,我们该谈一谈这个问题了。你们应该知道本周的
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团队的感受。现在,他们肯定宁愿自己去实现那个十一行的字符串填充函数。
相关文章推荐
- jbpm6.30下载安装
- Dell服务器之配置ipmi远程console管理
- 销售订单行上行号LINE_SHIPMENT_OPTION_NUMBER
- 使用spm构建seajs项目
- 学习笔记之rpm程序包管理功能解析
- JBPM——中文乱码
- jbpm4.3表结构和表字段说明
- JBPM4 常用表结构及其说明
- MPMovieplayerController添加新控件
- rpm 安装指令全 yum 安装 卸载命令
- 升级npm
- JBPM学习(四):运行流程实例
- 微信团队里有一枚老外产品经理,这是他观察到的中国互联网趣事
- 产品经理职责
- 使用IPMI工具实现对服务器的远程管理
- USE [EPPM] [dbo].[REFRDEL_CLEANUP]
- 《产品经理的二十堂课》—— 读后总结
- 拉勾沙龙会上,前大众点评产品经理运满满CTO分享的程序员职业规划
- 【图像处理】【SEED-VPM】7.RBL, UBL, Uboot的关系
- 国内首部基于JBPM5.4实战流程引擎开发(动态表单、模板引擎、公文管理系统)