逛论坛逛博客，经常会看到关于“造轮子”的争论。一般都是某某说自己正在写一个什么程序或是库，然后看到的人说这个已经有什么什么库了，直接用就好了，不要再去造轮子，把时间花在更有价值的地方等等。
先简单的“定义”一下“轮子”，粗糙地说，如果有一件事，存在一个大众都熟知的库（第三方模块）能做的话，那么这个库就是个“轮子”。如果我们再去写代码去做同一件事（嗯，并且在“能做的事情”上没有本质提高），那么我们就是在“造轮子”。 比如STL里的容器和基本算法，比如解析xml的库，比如跨平台的线程库，脚本引擎都自己做等等等等……
反对“造轮子”的人们举出的理由都是非常充分的：降低开发的时间成本、使用成熟的库可以减少软件的缺陷等等。这些理由基本上都是项目或是工程的角度出发，观点我也非常同意，如果是作为一个项目团队的管理者，我想我也会时时注意控制团队成员们造轮子的冲动。但我得承认，私下里，我也是个“造轮子”爱好者，平时业余时间里写的程序学的技能，都是在做“造轮子”的事儿。所以这篇文章里我简单说说喜欢“造轮子”的心理。
我觉得造轮子最主要的冲动造轮子的过程比较具有“技术含量”，或是有技术难度。没有轮子汽车是跑不起来的，同样的，没有那些基础的底层构件，应用程序也是空中楼阁。和汽车不样的一是，软件开发的“技术难度”大多集中在这些轮子上。这也可以理解为什么工程中管理者都会极力地避免制作这些轮子，因为费时费力还不一定能做到已有的软件库的水平，而且对于提高软件的质量没有明显的好处。但作为开发人员，特别是“有技术追求的”开发人员，就会觉得特别的郁闷。因为在这些“轮子”之上进行软件开发实在很难称得上有趣。所以“程序员”被戏称为“码农”也是贴切的，因为你只需要使用已经做好的材料，按照别人画好的图装起来就好了，你能提高的就是你拼接的熟练程度，这种提高很有限，而且这样的“拼接”工作几乎人人都能干得了，而且不用一年半载都能做得很熟练。那我们还有什么核心优势？也许这也是“程序员是吃青春饭”的原因之一吧。
当然会有很多程序员不满足于此，他们会不断地想办法提高自己的水平，追求更高的技术水平，学习更深更广的知识。而工程学科，学习知识的最好方法之一就是实践。学了一通操作系统的知识，就想自己试着写一些小小的操作系统内核；学习了编译原理，就想着自己造个简单的编程语言；学习了计算机图形算法，就自己搞个图形引擎。这个时候别人看来自己就是在造轮子。当然，绝大部分情况下，我们不会做得比已经有的库更好，毕竟这本身更多的就是为了学习而进行实践，自然会有不足会幼稚，造出来的“轮子”甚至一点可用性都没有。不过这不要紧，重要的在于自己实践了。很少有人会真正的“闭门造车”，在实践的过程中总是会不断地参考已经有的成熟的做法，在这个过程中揣摸和学习别人的手法、思路，了解别人的优点和缺点，从而不断地进步。这样的进步影响是多方面的，不仅仅提高了自己对于知识的掌握，也能更清楚原有库的使用方法、可能存在的问题，提高自己使用库和排查问题的水平，可谓一举两得。
就我自己学习 C++ 的经历来说，一开始，书看了很多，有的书还反复看，可是对于虚函数、模板等等C中不存在的特性还是一知半解，对于 STL 则更是觉得无从下手，只能看着例子感叹那些容器是多么的方便、迭代器是多么的精巧、函数对象适配器有多么的神奇，但就是不知道怎么用好，用得不对也不知道是怎么不对。后来参考着候捷先生的《STL 源码剖析》自己实现了一套简单的 STL ，在实现的过程中还不断比对 VS 中的源码，一个多月下来，进步显著，对于 STL 中的大部分关节都有了比较明晰的掌握，同时自己对泛型代码的理解和编写能力也提高不少。当然，我不会笨到在项目中使用自己写的 STL ，但自己写过一个简单的 STL 后确实是受益良多。
“纸上得来终觉浅，绝知此事要躬行”。从这个角度上来说，我私底下比较热衷于“造轮子”，也理解有同样“爱好”的人。
附注：
一、 当然，也有很多人认为喜欢造轮子是装B的表现，好像造个轮子就是为了看起来“牛”一点有深度一点，于是很多人不齿于此并对造轮子的人加以鞭笞。但这也侧面说明大家心里都认同，做轮子更不容易。我想大部在博客或是论坛上寻找技术交流的人本意并非“装”。想想看，当我们提个问题说X库的某函数这么用为什么不行，有人会说我们太菜，当我们试着实现X库呢，又有人会说我们在“装”，但我想其实大部人只是想获得进步、想有人能交流而已，也许自己看起来没有意义的东西，别人会有意愿参与讨论呢，所以，希望网络上的技术交流氛围能更宽容一点就好了。
二、 为了避免不必要的口水战，还是要申明一下，我自己也是非常反对在实际项目没有经过严格论证就随意发挥自己造轮子冲动的行为。除此以外，如果您对于本文有不同的观点，我愿意洗耳恭听。