为啥大厂热衷于造轮子？首先造轮子的事情比比皆是，随便截几个图看看。
其实不只是大厂，中型公司亦有不少造轮子的，俗话说人上一百形形色色。造轮子的原因大抵总结下面几类。
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 ，可能后人哀之而不鉴之，亦使后人复哀后人矣。
造轮子，不得不慎，与大家勉。
「关于号主：军哥，前饿了么、贝壳技术总监，目前是一名自由职业者兼公司顾问，乐于结交朋友，也欢迎加我微信与我做朋友（公号输入框回复“w”即可），朋友圈做个点头之交！
另外军哥写了一些，关于个人如何快速成长、深度思考、程序员或产品经理能力模型、架构，OKR干货，技术管理等电子书资料，公号后台回复 “9”获取，不谢。」
以往热文推荐：
更多精彩，关注我公众号，一起学习、成长
扫一扫
176万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
