很多人不理解 NPM 上 left-pad 这样的模块的意义

2016-03-24 09:48:23 +08:00
 sox
给那些也许还不理解 one-line module 意义的人

https://github.com/sindresorhus/ama/issues/10
11756 次点击
所在节点    Node.js
75 条回复
SharkIng
2016-03-24 10:51:51 +08:00
其实我的理解不就是 OOP 的东西么?把所有东西都一个个做成模块,然后需要的时候就可以用,尤其是哪些常用的东西。

这些东西是一行还是几行,放模块里调用起来肯定比你自己再写一遍要方便的多。

当然,这些东西是自己写一个模块在那还是调用现有的,我觉得这部是重要的。不重复造轮子固然重要,但是去找这些轮子也比较花时间的(除非你已经知道的或者很流行的)不过我觉得这部是讨论的重点。

重点是,这个东西好用,可以完成我需要的功能,我不需要重新写了,而且我可以反复利用,正好还被我知道了。
jsonline
2016-03-24 10:55:07 +08:00
@SharkIng 模块和 OOP 有什么必然联系?
sox
2016-03-24 10:55:27 +08:00
function noop() {}
jsonline
2016-03-24 10:55:50 +08:00
把 one line 变成 two lines 就可以完美避开这个问题了。机智不。
janxin
2016-03-24 10:56:08 +08:00
@keyanzhang 优秀的 stdlib 也不能完全覆盖所有的边角问题,就像很多其他语言程序员写多了之后都有自己的一个 stdlib-exts 一样。

然而一个 stdlib-exts 拆成几十个包的做法确实让人理解不能。
SpicyCat
2016-03-24 11:01:41 +08:00
我觉得这不是懒的问题,而是程序就应该这样写。一段代码,一种方式是自己写,另一种方式是用第三方库,并且是被广泛应用且证明可靠的库,那么必然要用第三方库。
如果第三方库看起来不是那么可靠,那么如果可能,就去 improve 这个库,然后再用。
如果人人都这样做,那将会产生个完美的社区,和完美的开发环境。
软件的成本中,写代码的成本是比较小的,调试和测试才是占大头,既然已经有可靠的代码可以复用,那为什么还要自己写呢?不管多短的代码,自己写都有可能犯错不是?
回想一下,你难道没有犯过让自己捶胸顿足的低级错误?

这次的事件,不是 do one thing and do it well 原则出了问题,而是社区管理的问题。不能因此而不让小的包存在。
congeec
2016-03-24 11:02:49 +08:00
这么短的代码,是直接复制过来,还是引入外部依赖呢?
我觉得引入模块就一个好处:标准化
sunjourney
2016-03-24 11:04:29 +08:00
解决的方案可以是多人维护一库,像 underscore 一样,把这些功能集成进去,包引用也减小不少
sox
2016-03-24 11:06:47 +08:00
@sunjourney 然而那已经让 underscore 闲得很臃肿了,现在 lodash 的做法是自己本身包含所有功能但是每个功能同时以 lodash.xxx 的名字发布。
Mattsive
2016-03-24 11:23:06 +08:00
根本就是 js 缺乏一个像样的标准库,发展出这种畸形的依赖,还能衍生出一套理所应当的设计哲学出来,那句话怎么说来着,不以为耻,反以为荣?
iwege
2016-03-24 11:29:03 +08:00
@sox 那是因为 js 作为一种要优化到最小的包存在,却缺乏有效的只集成需要的 function ,所以在工程上智能自己做拆分。

如果是可以使用 require('lodash') 的同时处理优化,谁在开发的时候还会喜欢去依赖一堆 lodash.xxx ?目前有一些工具在做,但是还是尝试性的。在正式项目中使用还有点担忧。
sox
2016-03-24 11:30:52 +08:00
@iwege 如果可以那样的话,为什么不直接只需要一个标准库 require('all') 然后自动分析用到的代码,然而不是做不到吗
leemail
2016-03-24 11:31:34 +08:00
[autocomplete by stackoverflow]( https://emilschutte.com/stackoverflow-autocomplete/)
sox
2016-03-24 11:35:02 +08:00
@iwege P.S. 你可以尝试 rollup/webpack2 的 tree shaking 功能,但是依赖 ES6 的 import 特性。
sox
2016-03-24 11:38:13 +08:00
@Mattsive talk is less
iwege
2016-03-24 11:40:43 +08:00
@sox 我最后不是说了么,有一些工具在做了.... 所以我不是很理解你说的做不到是什么意思.... 不管依赖什么,终归还是有人在特定条件下尝试性做了....
sox
2016-03-24 11:42:12 +08:00
@iwege 我的意思是始终要依赖构建工具
charlie21
2016-03-24 11:52:12 +08:00
开源是把双刃剑
Phariel
2016-03-24 11:55:32 +08:00
说到底就是专业级地实现轮子并维护轮子麻烦 有人帮你搞了何乐而不为?
damngood
2016-03-24 12:01:00 +08:00
如果是产品依赖这种库也没有什么问题. 和几行代码没关系, 只关乎你自己是否觉得这样 ok.

但是如果我是 library vendor, 一般如果不是真的非常必须的话, 我不会加入任何第三方的依赖进去. 如果一定要依赖的话, 那也会直接把源码 embed 到我的 library 里面去.

当然, 我这是在有着非常不错的 std library 支持的情况下. JS 的世界好像很不一样的感觉.

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/265944

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX