我们为什么喜欢重新造轮子

不要重新造轮子，是英文don't re invite wheel的直译。什么是轮子呢，我们一般认为一个通用中间件或框架，和实际业务没有直接关系的代码，就是轮子。这些代码虽然不是实质的业务逻辑，但是在一个项目中往往是担当骨架的作用。

程序员新手的眼中，这些代码就是经验的象征。在很多项目组中，只有经验丰富的老程序员才有机会去设计和选择这些轮子。可以设计可重用的干货代码，也就成为很多对技术有追求的程序员的努力方向。有几年工作经验，在技术上寻求发展的程序员大多都会自己设计和实现一些经典的轮子，这也成为了很多程序员成长的一步。

我们重新造轮子还有很多其他原因，今天我们在这里聊几个。

“这个功能太简单了吧，我自己写一个吧。” 的确，很多我们常用到的util function，他们可能会非常小，如果花5分钟就能写完，找现成的工具可能要花更长时间吧。这些function还可能是业务相关的，譬如计算下一个工作日。这些function由于太简单了，在一个项目里可能就有多个版本，每个版本可能一些微小的区别，有些可能有测试，有些可能连测试都没有。

”这个框架搞得太麻烦了，还不如我自己写一个。” 这句话我们在工作上应该经常可以听到，我们自己也许也经常会这么想。是啊，现在的很多框架都是高大上、大而全的。这种轮子大多都已经是车子了，不需要我们把轮子装上，只要我们把自己装进去就可以了。学习和使用这种框架需要消耗大量的精力和时间，而其实框架里很多功能都是我们不需要的。这种框架在维护上也是很消耗精力的。版本升级，可能带来的是性能，兼容性方面的很多问题。不升级版本吧，将来维护起来就会有很多问题。

“我这个需求比较特别，还是自己写一个吧。” 很多轮子之所以为轮子，就是因为他们具有很好的通用性。但是，也就并不一定那么适合我们手头上的问题。这种时候，是我们把问题搞复杂了或者没搞清楚么？还是我们真遇到了那么特别的需求？

“这个框架太难懂了，我还是自己写一个吧。” 自己写过parser的人大多数看到这里都会感到深有感触。其实parser在计算机领域应该已经是一个解决得很好的问题了，可是这个语法定义文件不好好看几本书真的是搞不懂啊。

“这个功能要是有API就好了，我调不了命令行啊，还是自己写一个吧。” 有些功能很好的开源项目，并没我我们需要的接口，这个时候，很少有人会耐得住性子去写一个Pull Request，打开代码把自己需要的功能拷过来就好了。

还有。。。，希望大家分享：）