引子

最近nodejs社区，又出了一件大事，来龙去脉的实在太多，这里只给一个link，就不展开了。NPM & left-pad: Have We Forgotten How To Program?
主要是想借着这个事情的“极端性”，聊聊我对重用的看法。

为何我们需要重用？

因为系统越来越复杂，我一个人不能写完全部的代码，所以我总需要在别人的工作基础上开发。
别人的工作基础，也许表现为某种服务、某种框架、某种函数库、甚至是某一个单独的函数。只要能够节约我自己的时间，我总是愿意去重用别人的工作成果。

最好的重用，当然是拿来就能用。所以，代码级的重用，是最为理想的。更进一步的说，一组封装完好的代码，要比“Copy & Paste”搞来的代码，更加好用。

虽然，我们经常会在社区里，鄙视那种直接跪求“代码”的家伙，但事实上：这的确是重用的最佳形式。假设你告诉了我一堆话，全是文字总结的经验，我还得自己理解，还得自己coding，然后还不一定对。岂不是又要再花几个来回？

泛泛而谈，我们是在重用他人的代码，但是要进一步分析的话，还可以再细分为几类：

要想节约自己的劳动，其实是需要有所付出的。至少，我们得付出一定的信任。相信那个代码，能够满足我们的需要，而且：不会给我们带来麻烦。

相信那个代码，在我使用的各种情况下，都能够表现正常——虽然那些代码，并不是我自己写的。

但是，事实上：这种信任，就是一种对于未知力量与未知能力的依赖。

假设，我们只依赖一个函数，而且这个函数，我们虽然没有自己编写，却对他进行了充分的测试。那么：这样的重用不会带来任何问题。

但是，如果我们依赖了20个包，这20个包，也不是完全独立，而是又各自依赖了几十上百个不同的包。说实话，我们的信任和依赖，是完全盲目的。因为我们根本无法对自己用到的所有的包，做充分、完整的测试。在项目投入生产之后，一切都是听天由命。

由于版本升级，这种情况，会变得越发严重。我依赖的某一个包，现在有了新的版本，也许修复了过去的bug，也许算法更加优化，但是也可能引入了新的bug。升级 or 不升级，这是一个很麻烦的问题。

在有了面向互联网的包管理工具以后，情况变得越发糟糕。我写了一个依赖描述文件，或者Gemfile，或者package.json，在执行依赖包下载的时候，同样的指令，却可能这一次一切正常，下一次彻底失败。因为——服务器端，发生了变化，某个包升级了，或者更糟糕：某个包unpublish了。

在微博上和朋友讨论，我形成了以下一些观点：

如果某个包，对我而言目前就够用了，那就不妨锁定版本。
- 虽然也有朋友说：如果不打算升级，维护一个私有版本，还不如自己写。但是，我认为锁定一个不再升级（也不再修改）的版本，并不算坏。
既然说到底，无非是某种信任关系，那么选择“品牌”，就变得非常重要。在社区里评价很高的框架和类库，知名（靠谱）的作者作品，是优选方向。
nodejs（JavaScript）的发展，还处于相当不成熟的早期，却又被npm这样先进的包管理工具，给刺激得蓬勃发展。我们也只能等待，有大牛横空出世，把一堆好用的函数，打包成一个大的package，然后大家继续愉快的使用。
命名良好，含义清晰的小颗粒的包，其实并不是坏事。只不过将来应该进化出更好的打包与包管理机制，来间接重用这些功能。更进一步的联想是：这样的发展方向，其实非常有利于将来计算机AI替代人类编程。