查看原文
其他

聊聊大中型公司都热衷于造轮子的故事

The following article is from 技术琐话 Author 老G先生

为啥大厂热衷于造轮子?首先造轮子的事情比比皆是,随便截几个图看看。






其实不只是大厂,中型公司亦有不少造轮子的,俗话说人上一百,形形色色。造轮子的原因大抵总结下面几类。

1、别人的轮子不好用
开源产品不少轮子已经齐备,但是往往存在满足80%-90%的需求的情况,为了10%造一个轮子,也大有人在。

2、为了彰显技术实力,好晋升
自己造的总是最好的。

3、真不是想造,你的需求优先级太低
一些中台团队,把服务用户分了一环二环N环,当你的需求处于三环外,你咋办? 指望不上,只能自己造呗。

4、通过造轮子,提升技术实力。
这年头跟人聊业务系统,水深水浅不好聊。聊聊JVM调优,RPC/message/分布式调度这些来上一套,也可以称之“统一沟通语言”,面试者和面试官皆大欢喜。

造轮子有没有好处?

要老G说,还真有。

毕竟业务为王,为了满足业务,要想尽一切办法解决问题。如果没有可用的轮子,自己可以改一个。当年dubbo没有维护了, 当当也折腾了dubbox。你依赖的工具/平台团队不接你的需求,这事还得自己造。

如何调优一家公司的诸多“轮子”?看起来是创新,可能是“闭门造破车”! 老G认为,有几个方向可以考虑。

1、在公司层面确定组织和业务的服务关系。
该Top-Down解决的问题,别让下面的小同学在那里抢地盘瞎折腾。比如某厂社交事业部和电商事业部,RPC框架/消息/日志/调度任务管理等等是否需要统一? 不需要也行,集团公司考核的是最终事业部的营收情况,你把精力更多放在做基础轮子上,做业务服务的人力就少了。当然这考验领导层的管理能力,花多少钱办事,是否是承包责任制,人//财/物/业算总账。

如果有中台团队来做基础中间件的功能,也明确对该团队的考核。社交事业部和电商事业部的需求,你都该满足。别区分亲疏,KPI 对齐了,让下面的人做事刷脸。

2、在事业部内部,拉通晋升条线的评选。
小部门A的事情,有业务结果,业务方埋单;小部门B的事情,有业务结果,业务方埋单;如果A和B 做的领域就是重复的造轮子,需要一个窗口看见,需要被考核,鼓励什么,反对什么。比如在某些公司,如果说不清楚做的平台,和公司内其他几个平台的关系,就不能晋升到某一层级。

3、正向鼓励合作。
据说微软员工的收入与impact相关。impact强调合作,在跟老板review的时候也要写自己跟哪些团队合作拿到哪些结果,通过合作团队拿到的业绩越多,绩效考核越高。从而避免内卷。


4、取决于技术带头人的见识。
俗话说上有所好,下必趋之。网易汪源老师感叹说,如果DDB这款产品早开源,就没有ShardingSphere什么事情了。别人开源的好东西,你今天看着不爽,自己造的可能2年就没人维护了。但是开源的还有无数人在增加新特性和修复bug,这就是open的力量。技术带头人要判断,什么东西应该站在巨人的肩膀上,什么东西应该保持自己的独创性,而什么东西应该分享出去,具有更强的生命力。

今天的某些轮子很红火,可能是历史长河的一粒沙。
今天你笑别人的代码low,可能后人哀之而不鉴之,亦使后人复哀后人矣。

造轮子,不得不慎,与大家勉。




往期推荐

被滥用的“架构师”!

构建健壮的分布式系统

阿里在云原生架构下的微服务选型和演进

代码规范 & 设计模式落地之路

SOLID 原则的可靠指南

万字长文 | 淘宝 10年架构演进

今天我要批判中台!

今天我要批判技术管理者

Apache架构师的30条设计原则!

今天我要批判架构师


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存