软件开发行业里有一个名词叫“造轮子”，似乎造轮子已经成为一种贬义词。每当有人提及“你这是在造轮子！”或者会说“你这是在山赛xxxxx”。被说的一方总会感觉到一丝凉意，甚至会有一种不被尊重的感觉。当我第一次听到有人跟我说“你这是在造轮子！”时，我变得异常敏感，即使是现在我也会感觉到一些不适。

    在开源世界里这种情况似乎已经是家常便饭了，无时无刻都会有人再说“你这是在造轮子！”。

    作为开发者无论从事的是低级的Ctrl+C,Ctrl+V 还是已经小有所成。都应该时刻谨记你的成果或许会在未来的某一天被人称之为“轮子”。当你的作品有幸被称之为“巨大的轮子”的时候，也要记得这只是通向成功道路上的坎坷的一部分。

什么是轮子？

    关于造轮子我们大家心中都有一个比较统一的标准，那就是重复制造那些已经存在了的(软件、功能、类库、框架）的行为。一旦你的(目标、功能)和某个产品或者项目一致，并且当你开始实现它们时，其实你就是在制造轮子。

    这里先提及一个概念就是“模仿”，“模仿”从出生到死亡我们一生都在做的事情。“造轮子”、“山赛”等其本质就是在模仿。微软在模仿、Google在模仿、三星在模仿、苹果也模仿。雷达、红外、人造卫星、人造心脏等等技术都是模仿的成果。

    我们说的轮子其实也是一种模仿，之所以被称之轮子主要还是评价人主观判断。因为这个世界上重复的事情太多了。

谁在鄙视制造轮子？

    如果你是公司的管理者，我敢保证你肯定不会喜欢看到公司同时进行那些相似甚至一模一样的产品研发。它们打从一开始就会面临从内部到外部的各种竞争问题。没有哪个管理者会喜欢遇见这样的事情。换做是我也不例外。我想马化腾也一定在“QQ企鹅”和“微信”之间也做过无数次的思想斗争。

    但当你是公司的一名开发者，而你试图开发一款ORM框架并争取在公司内部推广时。我敢保证大部分国内公司里总会有人跟你说：“你这是在制造轮子，我们已经有Hibernate、ibatis、Mybatis、Spring....，你为什么不用？”。当然你可以使用充分的理由去说服你的同事，你也可以保留自己的意见。不过把想法奉献给开源世界也会是一个比较不错的选择，因为在那里总有人会支持你的。

    当然还有人会说：“你制造的这个东西会很难维护，最后变成一坨Shit！”。有的时候遇到这样的情景还是坐下来，冷静冷静之后讲述一下你的设计思路以及出发点，没准会得到对方的认可。当然前提是作为设计者的你出发点应当是为了解决问题为前提条件，而不是只是为了制造轮子。

    也许你还会收到这样的评论：“就凭你？人家用了多长时间，多少人才有的成果，你一个人根本无法完成！”。没错07年我在北大青鸟接受培训时候就有过这种想法，而我就遭遇了这样的提问。现在回想一下Hibernate不也就是Gavin King一个人构建起来的么？

    没准你还会在一次很友好的技术讨论中忽然收到这样一句评论“你这是在造轮子！”。然后谈话或许会陷入尴尬或者你开始极力辩论它是不是轮子......

    ......

    无论如何，当你遇到上面这两种人时候，我想还是发挥沉默是金的优良传统把。毕竟与其浪费口舌解释为什么要造一个所谓的“轮子”还不如去实现它。因为纸上谈兵永远是属于书呆子们的。要记住：“手永远比嘴勤快”。当你做出来的时候收获的不只是这个所谓的轮子，你会看到跟深层的东西。与其争论倒不如去享受这份收获。说不定那个鄙视你的人还没有能力去创造这一切呢。

谁在制造轮子？

    我觉得这里有一篇文章说的很到位都是谁在制造轮子！

    同样的如果你在尝试做一款Web框架，那么请到OSChina项目分类中看一看，同类型的框架有多少。下面这张截图就是正在写本文时OSChina已经收录的Web框架统计数据。我也可以说有635个人和你在做同样的事事情，你们都是在制造轮子！我也是！

    ......

我赞成制造轮子！

    首先，如果打算在开源世界中贡献一份力量，就要做好制造轮子的心理准备。某类开源软件永远不是只有一种或几种，这不符合哲学、也不符合大众的期望。

    在生活中有很多人都将“Don't Reinvent the Wheel”--不要重复发明轮子 这句话奉为经典不可就范，并且以此为教条对身边的人进行教育。其实这类人被这句话束缚了。如果太较真它就会禁锢我们的思想。试想一下如果全天下数据库访问都只能通过JDBC来做，还会出现Hibernate、ibatis、Mybatis这类优秀的工具么？还会出现JTA，JPA，EJB3.0么？

    也许你会说Hibernate与JDBC、EJB与Spring本身就是不同事物的东西。但是就数据库访问角度而言Hibernate和JDBC做的事情是一样的，Hibernate就是JDBC的轮子。只不过这个轮子非常精美让我们觉得JDBC只是轮毅。

    试想一下，如果你写过一款数据库连接池。你就会不光了解到数据库连接池的工作原理，而且还会知道它面临的问题。这比仅仅知道怎么用和知道原理的人强多了，这种收获我想只有制造过轮子的人才能理解。

    各位读者你们觉得呢？