引子

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

为何我们需要重用？

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

我们怎么重用？

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

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

我们重用了什么？

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

• 经验：通常是某某问题，如何搞定之类。不仅仅是编程方面的经验，有了dockerfile这样的脚本之后，连运维的经验，都可以以代码的形式被重用了。
• 能力：用了XX方法、函数、lib，我就可以做XX了。往往某种功能、算法之类的实现。
• 思想：这通常会体现在我们使用框架的时候。使用某种框架，就是在接受（适应）框架作者的某种思想，并且依照这种思想来完成自己的功能。

重用为何会变成依赖？

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

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

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

依赖为何会变成问题？

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

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

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

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

如何避免重用的副作用？

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

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

重用的边界

说到底，其实是一个经济学原理：重用的收益随着重用的数量变大、粒度变小，而逐步递减；重用的成本，却随之递增。找到一个收益与付出的平衡点，就是重用的边界。

当然，随着网络速度的增加，包管理技术的成熟，重用的依赖度，会越来越深；重用粒度会越来越细（因为重用成本逐步降低），这是自然的趋势。如果称之为“越来越不会编程”，那就是不明大势了。

事实上，在这个趋势之中，新一代的程序员的知识结构，技能树，都发生了巨大的变化。擅长到stackoverflow提问，擅长在github搜索，能记住很多的关键字（便于搜索）却对语法不太熟悉。这些在老一辈程序员看来，都是能力退化的象征，其实却未必啊...