转载

我要重新发明轮子

“不要重新发明轮子”是总是可以听到的话，在评判一个设计的时候，总是听到这样的话。但是凡是不绝对，而对于这句话来说，很多情况下，都是错误的。我甚至都不能说出“大多数情况下不要重新发明轮子”这样的话，因为具体问题，实在没法用大多数还是少部分来概括。重用轮子有什么好处？省代码；轮子已经经过千锤百炼，质量有保障；轮子功能在逐步更新中，可以看到未来的获益。但是，也有一些情况让我无法重用轮子。

第一种情况，我只需要一点沙土，我不需要整座大山。

比如，我只需要一个StringUtil.isEmpty这样的方法，判断字符串是否为空串或者null，如果引入Apache Common Lib当然可以解决问题，但是我需要么？需要一个简化的系统，这也是很常见的场景。

第二种情况，dependency hell。

这种情况主要是考虑到目标库的体积过大，或者依赖包太多，或者存在潜在的包依赖的冲突问题。比如我的项目需要开源包A，但是A依赖于库B的1.0版本，而我现在的项目直接依赖于库B的2.0版本，那么怎么解决B的冲突问题，就会很头疼。

第三种情况，现有的轮子设计不好，想改进，发现却不易扩展。

这种情况也很常见，如果对于源码的修改是便捷、合法且合适的话当然最好了，要不然，兴许会自己实现一套。

第四种情况，发明轮子是一种相当的乐趣，而且，我要拿这个乐趣来吸引“有追求”的工程师。

这不是说笑，就身边的事实来说，我见过好多team都有自己的一套workflow的工作调度系统，基本上都基于SWF实现；都有自己的一套序列化存储系统，基本上都基于S3+Dynamo实现（一般都是S3放实际内容，Dynamo放索引和部分元信息）。这确实是一种浪费，但是本来工作中要遇到“有趣”的项目、有影响力的项目并不容易，拿着这样的东西去招工程师，很多时候至少听起来也挺牛逼的。

第五种情况，我当时根本就不知道有这个轮子存在啊……

这个有时候是最苦逼的一种情况了。但是，在实现一个简单东西的时候，与其去花时间精力调查有没有能用的轮子，以及哪个轮子最好用，可能还不如自己实现一套，而且还对代码聊熟于心，踏实得很。

以后再有人问起，为什么不重用XXX轮子的时候，多思考一下，为什么要重用呢？

正文到此结束