本文主要是介绍该不该重复造轮子？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目的不同，答案不同：
如果目的是对内部机制的深入理解那么，你可以大胆地去尝试造轮子
如果目的只是应用实现项目中的任务，那么你要避免造轮子，尽量依靠已有的资源，当然如果实在无法满足你自己的需求那么你可以造自己的轮子
对于，学习，想深入研究的人，造轮子很有必要！有很多人在写自己的编译器，自己的服务器，自己的操作系统。。就是这个原因。
///
今后要总结一些常见的轮子，如果觉得有必要可以自己做一个常用操作的轮子库，自己做过得，肯定很好理解，方便在今后类比去写代码节省时间；甚至模块化调用，这就更好了；
///
在程序界有一句话很流行,不要重复
造轮子。然而，这句话被滥用了。已
经渐渐沦为程序员懒惰的借口。甚至
因此而盲目指责那些勤奋的人。
大多数情况下初学者很难分清楚自己
是不是在重复造轮子。当我头一次听
到这句忠告的时候，我变得异常敏
感，在做什么之前都要判断一下是否
在造轮子。我跟大多数普通人一样，
容易受到他人只言片语的不良影响。
事实上很多时候，避免造轮子并不是
我的首要目标。我的目标是完成一项
任务，任务完成的速度要尽量快，质
量要尽量好。而不是去判断自己在不
在造轮子。
使用他人的现成轮子是实现快速任务
的一项捷径。然而，并不总是这样子
的。重复造轮子的正面是另外一句行
话:吃自己的狗食。在涉及到关键技
术点的地方，依赖他人的轮子容易造
成高风险。高风险的原因在于:第
一、它不是你写的。凭借注释和教程
获得支持很有限，当需要功能拓展或
者定制时，用起这个初期看起来很好
的轮子反而变得碍手碍脚了。第二、
当依赖轮子程度比较高的时候，那么
它容易限制自己的思维。有些功能用
轮子很难拓展，我们会推脱说轮子产
生限制。反而不去思考这些功能的提
出是否合理。第三、轮子可能是个一
次性产品，轮子的开发者不愿再花时
间维护。轮子不能与时俱进，那么就
会被淘汰。因此你的产品也会遭到淘
汰。“吃自己的狗食”的优势便是上述
情况的反义。善于吃狗食的人，并不
满足应用轮子做事，他们也会乐于阅
读不同轮子的源码。去粗取精，博采
众长。最终写出属于自己的锋利轮
子，达到期望的目标。
除了在关键技术点尽量不要使用他人
的轮子。还有重要一点，那就是不要
被“重复造轮子”这句话吓怕了。
windows有现成的记事本和扫雷，但
是每年还是有成千上万的大学生乐此
不疲的编写记事本和扫雷程序。更有
喜欢折腾的人尝试自己实现红白机上
的经典游戏。实践是最好的老师,学
生们并不是在重复造轮子，而是以提
高为自己的目的。许多开源项目的初
始目的并不只是为了做出一件产品，
而是为了学习。高手们都明白实践出
真知的道理，只是他们实践的技术含
量更高而已。所以，千万不要被轮子
吓怕，更不要以“轮子”为借口拒绝学
习成长。
上面我说了滥用重复造轮子的几个情
况以及他们的危害。现在我想将自己
的一点小小心得介绍出来——到底什
么时候不要重复造轮子?
若我有天想去九寨沟旅游，我想要选
择租车自驾游，我肯定不需要关心汽
车是怎么工作的。汽车对我来说只是
个工具，因为我的目标是旅游。情景
发生转变时，一切就变得不一样了。
假如我是个汽车设计师，我想测试汽
车在九寨沟的山路上能否平稳驾驶。
那么我不该关心九寨沟的旅游景点有
哪些，而应该关心汽车的内部构成怎
样，有没有问题，能否改进。
当使用轮子是为了达成一个日常任
务，或是以一个工具形态出现的时
候。那么请不要重复造轮子，除非为
了学习目的。我常常督促自己多多学
习一些shell命令，这样可以避免自
己写出一堆轮子脚本。同样的，当我
有个新奇想法的时候。我常常会上网
搜索有没有朋友已经实现，若有的话
直接使用现成的轮子即可。如果没
有，那么我只有亲力而为，自己去实
现。
有时候我会突然兴冲冲的充满野心。
用数据库用的很不爽，不是说“吃自
己的狗食”吗？那么把它写出来吧！
当然最后一筹莫展，因为这对我来说
太难了。也许我花上三五年时间都没
法彻底搞懂。同样的还有写个操作系
统、写个语言。这些东西也许最佳应
亲力而为，但如果它对于自己来说过
于复杂，那么就用它吧。因为这别无
选择。优秀的程序员不会乐于被这些
困难的东西牵着鼻子走，他们会尝试
消化并改善它们。
除了遇见这些困难的东西,有时候还
会碰到一些并不困难但是很占时间的
东西。没有必要盲目开工写这些占时
间的东西。在仔细分析已有的几种轮
子后可以直接选择其中最优秀的,在
它不能合适工作的时候就大刀阔斧的
修改它。这其中的关键之处在于你明
白轮子工作的原理，如果愿意，只要
花上几个月的时间，你能重新写出一
个来。
市面上有很多同类产品。明明有肯德
基，为什么还出来麦当劳、李先生之
类的。有时我会为开发产品的“山
寨”而耿耿于怀，这无疑是重复造轮
子的行为。别人已经有了，为什么我
还要做？几乎同样的逻辑，为什么要
重复实现一遍？这的确是重复造轮
子，但是这是必要的。原因有：1.虽
然产品形态和使用技术类似，但是后
台的资源是不同的。用户需要不同的
轮子，这样可以使市场有活力。肯德
基和麦当劳虽然都是快餐店，经营方
式和食品类型也差不多。但总有些微
差异，而正是这份差异带来了活力。
2.平台化、纵向发展。TX老是被网民
骂抄袭，但是似乎越骂用户量反而越
高了。因为TX造轮子有深厚的商业
目的，它希望做出一个整合一切的平
台。统一的平台给资源聚合带来了巨
大的好处，用户也会变得更加喜欢用
这个简单好用的整合平台。这种造轮
子行为从这个角度上说是非常有利
的
如何找到好轮子
如何找到好轮子其实在上面问题中已经很清楚了，你应当具备：
- 信息检索能力
- 外文资料阅读能力
- 代码阅读能力以及平时的积累
对于第一条，个人的信息检索能力是无法一蹴而就的，不过如果是还在等待我对此再说出一二三而不是去自己检索寻找方法的朋友，基本上已经没救了。
这里唯一需要说的是，如果想用百度那货去找技术资料的还是省省吧。
外文资料阅读能力也非一日之功，不过个人倒是有个小窍门，如果想要获得一些项目的HelloWorld入门教程或者服务器的配置，可以将检索语言限定为日语，因为日文用户的教程往往秉承了日本细致入微的精神，包括项目背景、需要的环境安装等等一些对初学者才有用的知识，在日文的技术资料中往往也会写的很清楚。
至于平时的积累，可能程序员都知道Github、SourceForge、Google Code这些优秀的项目托管网站。但是积累的意思并不是说有时间上去看两眼或者随便收藏一下这么简单。
比如我自己侧重PHP方面的项目，我的一个做法是找到Github下所有Follower大于300的PHP项目（其实一共不到200个其中很多还是php框架），然后一个一个像扫货一样，对其进行了解以及记录。
我的另一个做法是查看知名PHP框架，看看他们用了哪些轮子，比如在Symfony Reference中，你就能淘到Assetic、monolog 这样的好货。
最后一个办法是在Github上Follow一些活跃的作者，比如我的Following中就会显示我的Stars和Forks，里面自然也是我认为值得收藏关注的项目。
这篇关于该不该重复造轮子？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
