文章来源：https://blog.csdn.net/siddontang/article/details/24765201?utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2~all~first_rank_v2~rank_v25-12-24765201.nonecase&utm_term=%E7%A8%8B%E5%BA%8F%E5%91%98%E5%A6%82%E4%BD%95%E7%A7%AF%E7%B4%AF%E8%87%AA%E5%B7%B1%E7%9A%84%E8%BD%AE%E5%AD%90&spm=1000.2123.3001.4430
为啥要造轮子
对于一些程序员来说，喜欢自己造轮子可算是一个很平常的事情，我想可能有如下原因：
- 对于一些小的功能，不需要借助外部库，直接能够自己写完搞定。
- 对于一些大的功能，很多外部库不能很好的与自己项目整合，有时候还不如自己写一个。
- 有时候即使能用的外部库，因为程序员相轻的思想，就觉得自己写的nb，不用。
- 还有可能就是想深入学习某一个知识点，自己动手造一个。
我不觉得造轮子不好，曾今很长一段时间我都认为造轮子是体现自己能力很好的一种方式，但是现在越来越觉得，不要过分的去造轮子。
造轮子的教训
昨天，我需要对接amazon s3的存储，官方没有go语言的sdk，所以我就动了自己写一个的想法，即使我知道铁定有第三方的实现。
amazon s3的接口因为都是restful形式，同时签名机制已经非常熟悉（国内的存储服务接口几乎都按照这套设计的，除了几个奇葩的公司），所以我就开始写了，写完了之后，我在看一个第三方的goamz实现，发现跟我相差不了多少，一下子碉堡了。
我真的叫做没屁事了，这么浪费时间。
造还是不造？
很多时候，我们要克服自己造轮子的冲动。
对于一个需要实现的功能，我觉得首先可以考虑该需求是否有成熟的解决方案，如果有，使用的成本有多大？
譬如对于python来说，如果我们现在需要一套web框架，如果自己去写，而不用成熟的tornado，django这些的，我真觉得蛋疼了。而对于go来说，我到现在还没发现我们用起来趁手的web框架，所以就有了自己造的polaris。
如果项目进度有压力，多数时候我都倾向于通过集成外部解决方案来实现，而不是费时的自己去造轮子，因为这时候体现你能力的不是你写了多少nb的东西，而是将程序运行起来，提供服务。当然，你也不能找太挫的，或者完全无法驾驭的程序，那样后面就够你疼了。
即使真的需要自己去写一个轮子，还需要不停的问自己：我这个轮子稳定性如何，能否高效的运行，后续随着需求的变更我能不能很容易的掌控？如果发现自己搞不定，还是求助一下别人比较好。
如果我对某一个知识点特别有兴趣，想去深入研究并且有时间，那我觉得自己造几个轮子也算是很不错的事情。譬如我前段时间想重新深入了解网络编程，虽然有libev这些好用的开源库，我也基于他们封装了很多东西，譬如tnet，tpush，但是我仍然自己写了一个libtnet，写完了，我才有“啊哈，原来是这样“这种豁然开朗的感觉。
写在后面
随着现在github这类网站的流行，找到高质量的第三方实现已经变成一件很容易的事情，作为一个程序员，不能固步自封，总认为我自己写的才是好的，有时候“自己动手，丰衣足食”这种想法反而会累死自己。