有朋友问我：“道哥，想问下什么是不重复造轮子，我不是程序员，所以不太了解这句话的典故。”
这句话的出处我也不知道，但重复造轮子是经常会犯的错误。大到一家公司，小到一个部门、一个程序员，都有可能犯这种错。
也许直接把“重复造轮子”定义为错误有点过，但是在大多数情况下，重复造轮子都不可避免的造成了资源浪费，损失或大或小。
什么是重复造轮子？它为何会出现呢？
现代计算机技术的发展，是建立在无数先贤的集体智慧之上的。编程语言的发展也经历了若干个阶段，现代的编程语言已经变得越来越强大，每种编程语言都提供了大量的资源类库可供使用，让程序员可以通过很简练的语言，就能实现很复杂的功能。
我依然记得大学上编程课时，老师给我们举的一个例子：一个简单的按钮，在“可见即所得”的编程环境下（比如Delphi），通过简单的拖拽就能把这个组件拖到面板上，生成一个可以点击的按钮；而在老师自己上大学那阵子，要实现这样一个功能，则要从汇编语言写起，还要自己绘制按钮的图形界面。做这么一个小按钮，可能就要花上半天或一天的时间。而现在，这一大堆代码，全部封装到了一个简单的拖拽动作上，编程变得简单了。
可如果在编码的程序员，不喜欢这个按钮怎么办？那他可能就要自己写一个，从底层开始写起，然后绘制按钮的图形界面，最后让这个按钮变得可以点击。这就是“重复造轮子”，这个程序员花了数倍的时间，做了一个已经有的功能。
大多数情况下，自己实现一个一样的功能，是因为已经有的这个功能不好用。比如上例中，这个按钮太丑了，或者程序员想让按钮的点击动作发生变化什么的，总之已有的按钮功能无法满足需求，所以要自己重新造一个出来。在这种情况下，可以看做是一种创新，是对现有“轮子”的有益补充。
而“重复造轮子”之所以被诟病，往往是因为以下这些原因：
1. 程序员相轻。
别人写的东西总是没自己写的好，没自己写的顺手。如果代码风格不好话，维护起来也很麻烦 —- 这是一个看起来似乎很充分的理由。所以程序员都喜欢自己写一套东西，哪怕这个东西有开源的类库使用。我见过不少程序员经常把别人写的代码批成一坨shit。
2. 因为版权问题。
商业产品毋庸置疑，开源产品也是需要遵守License的（我在《互联网怎么赚钱 — 五》中解释过）。因为受到这样的客观限制，而只能选择自己重复造个轮子，这也是没办法的事情。
3. 因为开发进度和沟通问题。
比如一个公司经常有多个项目组研发不同的产品。在研发过程中可能会涉及到同样的组件，如果一个项目组实现过了，另一个项目组理论上来说就没有必要重复造轮子，完全可以代码复用。
但这只是理论情况，很多时候，因为要赶项目进度，所以做出来的东西是“能用就好”，而代码复用或多或少都会带来一些额外的工作量，以及后续可能会带来的维护工作量。而程序员又是很不善于沟通的，所以经常是脾气一上来就懒得再说，自己写了。
如果公司有一个好的技术负责人，能从一定程度上推动代码复用，降低项目组之间重复造轮子的成本。据说在苹果公司内部，乔帮主要求每个团队做出来的东西都要开放API接口，并把文档公布出来，其他部门可以直接根据文档复用这些功能，减少“重复造轮子”，这是一种比较可取的做法。
4. 因为一些“战略”判断。
比如我的老东家，认为以后不可能拿着Hadoop去和亚马逊和Google竞争，所以重复造轮子搞了个类似Hadoop的飞天系统；认为不可能拿着Android去打手机市场，所以把Android的核心组件之一JVM替换掉了。
我个人认为这样做不值得。从今天的互联网行业来看，有很多新兴公司通过包装Hadoop，包装OpenStack，为Android定制ROM，都取得了不错的成绩。如果老东家在成立的第一天就把精力集中在业务上，而不是重复造轮子的技术上，也许在云主机、大数据、手机三个领域早就独领风骚了，也不会有小米什么事。我依然记得当时云手机发布后（当时已经是推迟了半年发布，因为研发难度超预估），小米很紧张，被迫提前发布。
不过我现在说这些都是站着说话不腰疼，因为站在老东家高管的位置，对于成功的定义已经不是一家小小的创业公司和新兴业务能满足胃口的了。顶着那么大的压力，造出了那么大的声势，兄弟公司在一边也等着看笑话，谁去坐那个位置都是如坐针毡，送我我都不要。
最后，对于创业公司，我有一个建议：尽可能多采用开源技术，拥抱开源社区，把精力放在业务上，怎么快怎么来。至于自己研发个框架、研发个类库，那是大公司才玩得起的奢侈的事情，如非特别必要，远离之。
相关讨论：
多梦 七 10, 2013 下午 6:04
重复造轮子这种情况确实经常出现。因为大家的代码风格都不一样，有时候本来只需要在源码上作一些修改就可以实现想要的功能了，但是总感觉别扭，就改来改去，最后干脆全部重新写一遍，又费时又费力。
留言评论（旧系统）：