（续）关于代码重用性的研究

假如你是一个前端，现在需要在网页上添加一个日期选择器。你自估要多久？

聪明的程序员不会重复劳动，他会复制已有的代码。

更聪明的程序员连复制都懒，他会把这些代码写成组件，下次可以直接使用。

 

于是，框架就这样诞生了。起初框架的目标很明确：我需要重用这段代码，所以把它们提取出来。

但后来却发现，有个地方我需要的是一个稍微有点变化的日期选择器，直接照搬代码显然是不行的，

但是聪明的程序员不会去重复劳动，于是他选择修改框架代码，让他同时满足2个需求。

 

后来的后来，需求越来越多，终于有一天，框架变的很大。

然后就有人抱怨了，尼玛我只需要这么一个简单的功能，你给我来这么多代码。

有洁癖的程序员就不满意了，他决定自己重写一个框架。

 

于是，越来越多的框架诞生了，都声称有很多功能，怎么怎么方便。

然而这些框架最终都为了他们所追求的功能和方便付出代价：代码越写越多，到最后只能重构，甚至是重写。

对于新人来说，或者去学习一个很复杂的框架，虽然他可能只需要一个功能，或者自己重写。

 

以上就是程序员和他的伙伴们的故事。

让我们重新梳理下为什么框架越做越多的原因：

1. 需要功能A，所以写一个框架。

2. 需要基于功能A开发功能B，所以改框架添加功能。

3. 需要基于功能B开发功能C，所以改框架添加功能。

4. 只需要功能A，尼玛这框架功能太多了，我还是自己重写个吧。 - 或者- 需要基于功能A开发功能 D，发现改起来越来越复杂，于是选择重写。

5. 回到步骤1

 

当然，并不是所有框架最后都被重写了，然而实际上，即使作者自己不重写，也会有其他人去重写。

出现这个现象的本质问题是什么？再重新看上面的步骤4，它是导致重写的导火线。

因为我们只能使用框架的全部功能，而不是部分功能，当我们对他的任何一个功能不满足时，就必须整个重写。

举个现实中例子：我需要一个博客系统，但是wordpress的XXX功能我不满意，所以我喜欢自己开发一个。

我需要一个日期选择器，但是XXX框架提供的日期选择器XXX地方不好用，所以与其去改他的代码，我不如自己开发一个。

 

作为一个完整的东西，要找不到一个不满意的地方着实很简单。

所以就不断有后来者想要做一个完美、大而全的东西。

所以解决这个问题的关键是：要允许使用部分功能，而不是全部。至于怎么做到，我想只要听从党的指挥就可以了。