谈谈“不要重复发明轮子”

只身在他乡，常常想起我的父亲，在我们当地他是出名的木匠师傅，一手掌脉设计建造了许多建筑物，留下了很多赞誉，不过现在人年龄也大了，就没有当木匠师傅了。他曾经给我说过，在工程领域，文官永远要输给武将。其意思就是说，一个纸上谈兵的人永远要输给一个不断实践的人。这样的道理或许有些绝对，也不会有人不懂，也许是因为从小就在这样的氛围中耳闻目染，所以我一直都是一个乐于动手实践的人。

 

在软件工程领域，有一句著名的话，叫做“Don't Reinvent the Wheel”--不要重复发明轮子。这句话说得非常经典，也非常有道理。但在生活中，我就发现时常有些人常常被这些名言所束缚，其实我觉得“不要重复发明轮子”也只是站在某一个角度告诉IT人员的一个道理，如果将其奉为不可叛逆的金科玉律，就会束缚我们的思维，阻碍我们的步伐。

 

我是一名从事Java相关开发工作的IT人员，回忆当初自己自学java走过的路，我戏剧性地发现自己就是一个典型的在不断重复发明轮子的人。一个东西别人已经写过了，我将其下载下来，理解他的思路，重新自己再写一遍，或者再改造一遍，通过这个过程，我有很迅速的提高和积累，收获真的不是一点两点。

 

在论坛中，当一些热爱软件开发的同行们贴出一个自己写的东西，下面的留言总会出现，“又是一个重复的轮子”之类的跟帖，但我发现更多的留言是热心指出“如何如何。。。会更好”之类的跟贴，后一种跟贴是抱着一种欣赏交流的态度，非常好，因为我也是这样。

 

试想一下，如果你写了一个数据库连接池的小组件，你将对jdbc有深刻的认识；如果你写了一个IoC容器，你将对各种设计模式，反射机制等有更深的认识；如果你写了一个缓存框架，你将至少会在软件性能优化上加入自己的思考；如果你写了一个js library，你将对js的使用有更深刻的体会。如果......。这些工作永远比每天写几个Ation，几个service，几个DAO让我们提高积累得更快，从而也更清楚地认识自己真正匮乏的是什么。

 

我们不追求一定要让自己的小组件大范围推广，只因为我们还有几分对软件开发的热情，我们乐于学习，愿意研究，我们愿意付出一点时间来不断提高自己，因为这样不仅能让人体会到作为一个男人的那种充满斗志的“孤芳自赏”，也更让我们变得更有价值和竞争力。你觉得呢？

 

 

    我个人觉得，重复发明轮子没有什么不好的，重复发明轮子也是一种艺术。如果说一个把轮子的原理掌握得都差不多了，觉得没必要再去发明个了，那么我觉得这样还是比较好的。但是如果说一个人只知道这个是个轮子，可以用来做什么，但是对其原理完全不知道，那么就要想想是否该去了解下轮子的原理，甚至自己做个轮子了。这个过程所能学到的东西，比把这个轮子用100遍学到的还要多。
    一个轮子发展在某个程度，由于基础架构或者其他问题，所暴露的问题就多了，如果没有重复发明的轮子，又怎么能有新的轮子来替代呢？不然，struts1出来就够了，为何出了那么多MVC框架。如果没记错，“Don't Reinvent the Wheel”这句话是 Rod Johnson 说过的，但是看看spring，多么大一个轮子啊，springMVC,SPEL......

这里酸葡萄很多~

这个社会的通病，就是太浮躁。踏实做事的人不多~

社会的一个基本规律就是：学习—》理解—》发展—》创造，重复发明轮子其实也是这样一种过程

不要重复发明轮子 是从工程角度出发说的

在实际项目中，尽量用已经通过工程证明 的可用的轮子
如果一定要做一个，那也必须要在对已有轮子充分了解下，能够保证自己做的轮子 比已经有的轮子 有非常明显并且本质的好处


至于个人通过做轮子学习，自己的时间当然自己可以支配，愿意去读源代码愿意去造轮子去冒险都可以，只要自己觉得值得就行
但是不要让公司和团队为个人的轮子去冒险

这个说明很中肯，我很赞成。

不过现在某些人明显有些过了，已经到了除了会用轮子其他什么都不会的地步，而且这些一个一个的轮子，慢慢变成叶子，遮挡眼睛的叶子......

楼主可以无视那些看不起“发明轮子”的人，自己写过跟自己看过是两回事

其实这句话应该这么理解："要有发明轮子的能力，但是没必要去发明已有轮子"，但是大多数人可能是“既然有个能用的轮子，为什么还有了解轮子是怎么运作的？”

不管是个轮子还是车子·从中学习到了东西就是合理的~~呵呵