为什么 left-pad 只有 11 行代码，也能成为众多库的依赖？

[mthli]

首先申明，本人没怎么写过 JS ...

https://github.com/azer/left-pad

不算空行的话， left-pad 真的只有 11 行，当然再处理一下可能几行就搞定了。

那么问题来了，为什么这么短的代码，也能成为众多库比如 RN 的依赖？

难度人们已经懒到这种程度了？

[yangxiongguo]

http://www.v2ex.com/t/265944#reply0

[mthli]

@yangxiongguo 有点意思。

[yangxiongguo]

@mthli
感觉我在 “以己之矛攻己之盾”

[ChiangDi]

这是很好的，看看 SICP 第一章。

[v1024]

让自己的代码只做最重要的事。
这儿一个 11 行，那一个 11 行，多了之后弄个 utils ，臃肿，也不专注。

[shyling]

是的～模块化本身就是人懒。。有什么不好的嘛

[chmlai]

npm 的小模块哲学

[Wangxf]

这是多米诺骨。。。首先开始写一个项目的用了这个包再发包，然后另一个程序猿用了这个程序猿的包，再另一个程序猿，如此往复下去，你就会发现某个大型项目居然会有你的包，而你的包出问题有可能导致整个项目挂掉，说到底所谓 unix 哲学虽然讲究只做好一件小事然后集合小事办大事，但是某个人对于这么多所有的小事是无法掌控的，

[daysv]

@shyling 然而懒才是发展的第一驱动力

[magicdawn]

@Wangxf

然而我敢说 Node.js 中 100% coverage 是最多的。。。

[zhujinliang]

假设我需要处理字串了
首先我要先去 google 搜索一下应该用什么包
然后我要看看这个包应该怎么调用，至少要读一遍 readme 吧
然后 install ，写引用，写调用
怎么看也不如自己写两句话来的快啊

好吧，假设从性能考虑，毕竟 string 操作会牵涉出一大堆问题
a 包说我是 fast left pad
b 包说我 3x faster than A
c 包给出了 benchmark
...
开始晕了，我觉得还不如从算法开始调研呢

后期维护考虑，一个组件总有机会得到性能提升的吧
然而我在 golang 上的体验是，妈的这个包又不兼容了，编译不过都是给面子的，有时候得跟进包里调试，最终你会发现辣个人不经意地改了某处导致你的程序 bug

[wingoo]

而且这边会有一个问题, 就像这次 left-pad 包挂掉一样, 如果某个深度依赖的包被黑(被黑的意思是不管你指定啥版本, 啥版本我都给污染了)
那么会不会有很大的安全风险?

[sox]

@zhujinliang 如果是相对简单的包，那了解如何使用也很快，而且测试、维护成本更少。如果是实现 重要功能的模块花费更多时间熟悉也是有价值的。

[bramblex]

Monad 定义还只有两行呢…但是绝大多数程序员都搞不懂

[allan888]

@zhujinliang 人家写了 11 行，你自己写真不见得只要两句话。
字符串长了是个合格的程序员总会想想效率吧，而你自己写的还得好好想想到底高效不高效。
举个例子，假如 left pad 也许有什么黑科技，用了一些普通人根本看不懂的 trick 写了个特别高效的算法，那么用的人肯定很多，你用大家都用的就得了，管那么多干啥，反正至少不比你自己写慢。
然后你觉得这个算法不可能有黑科技，那大多数人怎么知道没有，确定“没有”更好的算法要求的功力根本不比知道更好的算法低。
用库的话基本上至少库里面那部分都是“优秀”的，你自己写的话不能保证，就这么简单。。

[martianyi]

如果这次不是 11 行的 left-pad 而是 1100 行的大包被撤了引起恐慌是不是你就不会问这个问题了？

我引 11 行的三方库和引 1100 行的三方库有区别吗？都是为了解决我的问题而已。

[mthli]

@allan888
@martianyi

在我看来这样的代码可能使用 Gist 更合适。

[SourceMan]

现在是一行（ N 多 NPM 包不包括头尾，只有一行），你确保以后为了兼容不会变成多行？
然而，我们为什么要关心实现它需要多少行，直接使用它就好了。
让它变成一个黑盒，通过项目本身大覆盖的测试用例保证可用性

[6IbA2bj5ip3tK49j]

前端毕竟走在潮流前端，新时代的搬运工。
11 行的包都需要引入，都不用考虑整个项目的掌控问题吗？

[allan888]

@mthli 这样的 gist 多了以后需要来个谁统一管理一下不？