谈谈自己造轮子

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

为啥要造轮子

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

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

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

造轮子的教训

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

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

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

造还是不造?

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

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

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

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

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

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

写在后面

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

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