为什么要鼓励重复造轮子
作者:丁仪
来源:https://chengxuzhixin.com/blog/post/wei_shi_me_yao_gu_li_zhong_fu_zao_lun_zi.html
“不要重复造轮子”恐怕是仅次于“php是最好的语言”之后最流行的话了。各种论坛,各种文章,都在说不要重复造轮子,那我们到底造不造呢?回想这几年的工作经历,个人或团队重复造的轮子也有几个,整体上还是比较认可这种工作方式的。在适当的时机造轮子有时候也是最佳选择。
不重复造轮子的理由,主要就是通过复用减少工作量,而且开源社区的很多项目质量也比较可靠。比如 Spring 框架,在很多大公司的重要项目中都有使用,事实也证明了可靠性,恐怕没有几个团队会自己实现一套 IOC 框架并用于生产环境。开源项目集聚了很多优秀程序员的心血和付出,经过大规模的使用和小心谨慎的问题修复,无论是架构设计还是项目质量,大部分还是有保证的。自己造轮子所面对的工作量、缺陷数、安全性是比较大的阻碍,投入产出比不高。
但是,我们也发现,有很多人长期处在仅仅使用开源框架的层面,没有进一步深入。虽然工作了挺长时间,但是技术深度还浮于表面。其实道理很简单,只有真正理解框架的原理,才能更好地使用框架。对于能够复用的东西,优先考虑复用,少造轮子。但是造轮子也不一定是坏事,站在前人的肩膀上,也可以有更多突破。
造轮子,能够极大提升技术水平。比如曾经做爬虫模拟用户登录的时候,最初仅是依靠 httpclient 访问 URL,然后写了很多业务代码做数据分析。但是过了 3 个月,发现有大量重复的代码,而且整个系统有一种确定的模式,于是造了一个爬虫模拟用户登录的框架,极大提升了开发效率,技术水平有了一次飞跃。
造轮子,能提升个人影响力。比如曾经火了一把的 flv.js,作为 B 站在用的网页播放器让作者谦谦火了一把,让大家开始关注这个年轻的 95 后,并开始为其抱不平。谦谦是高中学历,在程序员群体中属于不太突出的,工资也只有 5000 左右。如果没有 flv.js 开源项目,可能一辈子也得不到大家的关注。现在工作能力得到了认可,想必会有不错的发展吧。
造轮子,解决不能满足的需求。Spring 框架解决了 IOC 和 MVC 问题,Mybatis 解决了数据存储问题,dubbo 解决了分布式调用问题,然而业务实现还需要具体问题具体分析,case by case 进行设计。一个表单的数据采集,就有数不清的业务场景,针对性地设计了几个产品来满足不同的业务诉求。开源轮子也无法完全满足所有场景,所以有 RocketMQ、Tair、diamond 等内部实现。
造轮子,能推动公司技术进步和沉淀。这可能是所有互联网公司的“通病”,对技术创新比较看重,晋升、加薪都有倾斜,同时对一般的日常维护比较淡漠。所以同一家公司往往有多个框架或产品,在解决同一类问题,同时在各自重点突破的领域内也建立了一定的技术壁垒。不过最终往往会走向统一,由其中较为突出的一个逐渐取代其他框架或产品,从而完成了公司的技术突破。
要不要造轮子呢?可能还得具体问题具体分析,综合考量。无论是个人还是组织,最好是鼓励高水平创新,防止低水平重复。重复造轮子不可怕,没有思考和创新,仅仅是 copy 了一份,一定是没有价值的重复工作。在充分调研和思考后,出于谨慎的权衡考量,造出一个有特点、有突破的新轮子也是大功一件。
微.信.搜.一.搜.程序之心,每周一三五原创更新。
推荐阅读: