"不要重新发明轮子"是从国外IT界流传进来的一句话, 目的是告诫我们尽量使用现有的技术和组件, 不要随意重新发明这些技术和组件.
但是任何事物都要一分为二的看待，都有它的好处和坏处，这里从企业和个人的两个角度来分析他们的优缺点。
现在的开源产品大行其道，已经为很多公司的技术发展起了非常重要的作用，尤其是中小型公司，但是我们也了解到某些大的公司似乎对重新发明轮子非常的感兴趣，觉得开源产品没什么了不起，不可采用，风险太大，我一直没有理解他们所说的风险太大指的是什么风险，可能大家都对开源产品不了解而产生的心理风险太大了吧。
从企业的角度来看，不重新发明轮子是可取的，并且是明智的。对于一些技术方面，开源产品已经有了非常标准或者精湛的实现，比如ORMapping，hibernate经过几年的发展，已经做得相当好了。自己如果重新去做ORMapping工具，得到的结果往往是质量属性差的太远，性能很低下或者支持的模式也不多，造成了下游链中业务设计人员，业务开发人员的极大痛苦。并且经过几个产品的发展之后，可能已经被修改的面目全非，有没有人出来进行重构，造成的结构就是这个糟糕的实现变成了产品的一个负担，历史包袱。架构师在设计的时候，总是避开他的弱点来考虑，往往造成一些架构师的一些想法无法付诸实践。如果技术平台中的很多模块，比如ORMapping，Report，BI, Workflow等都自己重新发明轮子，那么这就是一个糟糕的技术平台，对产品的发展非常的不利。历史包袱会越来越大，没有人敢于跳出来说完全摒弃这些糟糕的实现，因为要承担很多的风险。因此企业应该积极的要求架构师和设计人员评估开源实现，并且进行应用。好的做法是：
- 完全引入开源实现，并且通过接口隔离，方便对同类开源实现的替换。
- 扩展开源实现，实现自己的特殊功能，这样就享受不到某个实现的升级策略。
从个人的角度来说则与企业不同，要积极的发明轮子，这叫做创新，不重新发明轮子其实是抑制了创新思想，非常不利于个人的发展。
经常在面试的时候就会看到，你们项目采用的架构是什么，Spring+hibernate+JSF/Tapestry等等。当你问他对这些开源产品有什么体会和具体的评价的时候，通常答非所问。当你问到对于他们的核心源码了解多少时，支支吾吾不知道说什么。当你问到你们都扩展了他们那些功能时，通常是一脸茫然，当然这里说的是大部分的情况，包括以前的我，一些人除外。因此我们必须摆正心态，积极的吃透这些产品的精髓，再加以创新，这个创新的过程既是重新发明轮子。因此我们不要做纯粹的模仿者，要做积极的模仿者，积极的探索，积极的发现问题，积极的创新解决。
因此对于是否重新发明轮子，可能决定的因素还很多，这里只是从企业和个人的角度来分析，也是对之前的自己做一次反思。