重新发明轮子

重新发明轮子

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

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

比如,我只需要一个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轮子的时候,多思考一下,为什么要重用呢?

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接《四火的唠叨》

分享到:

发表评论

电子邮件地址不会被公开。

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>


Preview on Feedage: