“ 不要重新发明轮子” 是总是可以听到的话，在评判一个设计的时候，总是听到这样的话。但是凡是不绝对，而对于这句话来说，很多情况下，都是错误的。我甚至都不能说出“ 大多数情况下不要重新发明轮子” 这样的话，因为具体问题，实在没法用大多数还是少部分来概括。重用轮子有什么好处？省代码；轮子已经经过千锤百炼，质量有保障；轮子功能在逐步更新中，可以看到未来的获益。但是，也有一些情况让我无法重用轮子。
第一种情况，我只需要一点沙土，我不需要整座大山。
比如，我只需要一个 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 轮子的时候，多思考一下，为什么要重用呢？
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》