标签：造轮子

写下这篇文章，主要是对我近段时间工作的反思。

为啥要造轮子

对于一些程序员来说，喜欢自己造轮子可算是一个很平常的事情，我想可能有如下原因：

• 对于一些小的功能，不需要借助外部库，直接能够自己写完搞定。
• 对于一些大的功能，很多外部库不能很好的与自己项目整合，有时候还不如自己写一个。
• 有时候即使能用的外部库，因为程序员相轻的思想，就觉得自己写的nb，不用。
• 还有可能就是想深入学习某一个知识点，自己动手造一个。

我不觉得造轮子不好，曾今很长一段时间我都认为造轮子是体现自己能力很好的一种方式，但是现在越来越觉得，不要过分的去造轮子。

造轮子的教训

昨天，我需要对接amazon s3的存储，官方没有go语言的sdk，所以我就动了自己写一个的想法，即使我知道铁定有第三方的实现。

amazon s3的接口因为都是restful形式，同时签名机制已经非常熟悉（国内的存储服务接口几乎都按照这套设计的，除了几个奇葩的公司），所以我就开始写了，写完了之后，我在看一个第三方的goamz实现，发现跟我相差不了多少，一下子碉堡了。

我真的叫做没屁事了，这么浪费时间。

造还是不造？

很多时候，我们要克服自己造轮子的冲动。

对于一个需要实现的功能，我觉得首先可以考虑该需求是否有成熟的解决方案，如果有，使用的成本有多大？

譬如对于python来说，如果我们现在需要一套web框架，如果自己去写，而不用成熟的tornado，django这些的，我真觉得蛋疼了。而对于go来说，我到现在还没发现我们用起来趁手的web框架，所以就有了自己造的polaris。

如果项目进度有压力，多数时候我都倾向于通过集成外部解决方案来实现，而不是费时的自己去造轮子，因为这时候体现你能力的不是你写了多少nb的东西，而是将程序运行起来，提供服务。当然，你也不能找太挫的，或者完全无法驾驭的程序，那样后面就够你疼了。

即使真的需要自己去写一个轮子，还需要不停的问自己：我这个轮子稳定性如何，能否高效的运行，后续随着需求的变更我能不能很容易的掌控？如果发现自己搞不定，还是求助一下别人比较好。

如果我对某一个知识点特别有兴趣，想去深入研究并且有时间，那我觉得自己造几个轮子也算是很不错的事情。譬如我前段时间想重新深入了解网络编程，虽然有libev这些好用的开源库，我也基于他们封装了很多东西，譬如tnet，tpush，但是我仍然自己写了一个libtnet，写完了，我才有“啊哈，原来是这样“这种豁然开朗的感觉。

写在后面

随着现在github这类网站的流行，找到高质量的第三方实现已经变成一件很容易的事情，作为一个程序员，不能固步自封，总认为我自己写的才是好的，有时候“自己动手，丰衣足食”这种想法反而会累死自己。

今天刚好看到了一篇文章一位码农的几点思考，里面的观点我很赞同，与大家共勉。

谈谈自己造轮子

标签：造轮子

原文地址：http://blog.csdn.net/siddontang/article/details/24765201