为什么要鼓励重复造轮子

“不要重复造轮子”恐怕是仅次于“php是最好的语言”之后最流行的话了。各种论坛，各种文章，都在说不要重复造轮子，那我们到底造不造呢？回想这几年的工作经历，个人或团队重复造的轮子也有几个，整体上还是比较认可这种工作方式的。在适当的时机造轮子有时候也是最佳选择。

不重复造轮子的理由，主要就是通过复用减少工作量，而且开源社区的很多项目质量也比较可靠。比如 Spring 框架，在很多大公司的重要项目中都有使用，事实也证明了可靠性，恐怕没有几个团队会自己实现一套 IOC 框架并用于生产环境。开源项目集聚了很多优秀程序员的心血和付出，经过大规模的使用和小心谨慎的问题修复，无论是架构设计还是项目质量，大部分还是有保证的。自己造轮子所面对的工作量、缺陷数、安全性是比较大的阻碍，投入产出比不高。

但是，我们也发现，有很多人长期处在仅仅使用开源框架的层面，没有进一步深入。虽然工作了挺长时间，但是技术深度还浮于表面。其实道理很简单，只有真正理解框架的原理，才能更好地使用框架。对于能够复用的东西，优先考虑复用，少造轮子。但是造轮子也不一定是坏事，站在前人的肩膀上，也可以有更多突破。

造轮子，能够极大提升技术水平。比如曾经做爬虫模拟用户登录的时候，最初仅是依靠 httpclient 访问 URL，然后写了很多业务代码做数据分析。但是过了 3 个月，发现有大量重复的代码，而且整个系统有一种确定的模式，于是造了一个爬虫模拟用户登录的框架，极大提升了开发效率，技术水平有了一次飞跃。

造轮子，能提升个人影响力。比如曾经火了一把的 flv.js，作为 B 站在用的网页播放器让作者谦谦火了一把，让大家开始关注这个年轻的 95 后，并开始为其抱不平。谦谦是高中学历，在程序员群体中属于不太突出的，工资也只有 5000 左右。如果没有 flv.js 开源项目，可能一辈子也得不到大家的关注。现在工作能力得到了认可，想必会有不错的发展吧。

造轮子，解决不能满足的需求。Spring 框架解决了 IOC 和 MVC 问题，Mybatis 解决了数据存储问题，dubbo 解决了分布式调用问题，然而业务实现还需要具体问题具体分析，case by case 进行设计。一个表单的数据采集，就有数不清的业务场景，针对性地设计了几个产品来满足不同的业务诉求。开源轮子也无法完全满足所有场景，所以有 RocketMQ、Tair、diamond 等内部实现。

造轮子，能推动公司技术进步和沉淀。这可能是所有互联网公司的“通病”，对技术创新比较看重，晋升、加薪都有倾斜，同时对一般的日常维护比较淡漠。所以同一家公司往往有多个框架或产品，在解决同一类问题，同时在各自重点突破的领域内也建立了一定的技术壁垒。不过最终往往会走向统一，由其中较为突出的一个逐渐取代其他框架或产品，从而完成了公司的技术突破。

要不要造轮子呢？可能还得具体问题具体分析，综合考量。无论是个人还是组织，最好是鼓励高水平创新，防止低水平重复。重复造轮子不可怕，没有思考和创新，仅仅是 copy 了一份，一定是没有价值的重复工作。在充分调研和思考后，出于谨慎的权衡考量，造出一个有特点、有突破的新轮子也是大功一件。