总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 技术琐话 「老G先生」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

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

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

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，可能后人哀之而不鉴之，亦使后人复哀后人矣。

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

文章目录