对程序员重复造轮子的几点思考

　　今天聊下程序员重复造轮子方面的话题，谈下自己的看法。

　　对于重复造轮子，简单来说就是一个企业或组织，本身存在可用的开源组件，项目或基础库，但是很多开发团队还自己重头手写一套自己的框架或组件的情况。

　　实际上这种情况在各大互联网公司相当普遍，类似腾讯内部本身也分了很多的BG事业部，各个事业部之间往往都存在重复开发相同的组件或基础平台的情况。在19年腾讯内部也就该问题启动了内部的开源协同，具体如下：

　　开源协同的基础工具，包括技术图谱、专门讨论技术的社区码客、代码管理工具等。让技术人员能够在固定的地方找得到各种技术，可以直接拿来用。

　　类似当前我们常说的微服务开发框架，服务注册中心，微服务治理等都可以看到，实际当前存在多个不同的开源项目，类似阿里，华为，腾讯都推出自己的开源开发框架和环境。我们随时都在说不要重复造轮子，但是实际情况往往又是不断在重复造轮子。

　　今天写这篇文章还是想谈下对该问题的一些看法。

　　为何会出现重复造轮子的情况？对于不同的组织，团队往往都有自己的理由，但是总结下来说主要还是体现在以下几个方面。

　　开源项目无法满足需求

　　简单来说就是开源项目无法满足特定项目在特定场景下的一些需求，在这种情况下如何选择开源项目往往存在对项目进行代码改造方面的问题。那么后续开源项目本身的版本升级往往就比较麻烦，这个就很难保证升级的平滑性。

　　同时对于开源项目别人的代码进行大量的改造往往也是一个危险动作，特别是程序员对开源项目本身的底层逻辑不太清楚的情况下反而引入更多的问题和风险。

　　开源项目太复杂到性能和敏捷

　　一个开源项目如果要做到能够支撑不同的业务场景或技术场景，那么这个项目本身就会不断地抽象，底层模型也就越来越复杂。在这种情况下虽然能更好地支撑上层业务场景的多样性，但是由于底层复杂模型牺牲了相应业务场景下的性能和敏捷性。

　　举个简单的例子来说采用JDBC直接访问特定数据库，其性能肯定是好用采用O/R Mapping框架的。ORM框架需要考虑对多场景，多数据库适配支持，那么一定是引入了更多的复杂性，并牺牲了一定的性能。

　　类似的还有很多例子，比如传统我们谈消息中间件，为了满足复杂业务场景都需要支持事务处理和数据持久化，在这种情况下性能一定降低，这也是后续又出现了类似Kafka等消息中间件的一个重要原因。

　　程序员的技术狂热

　　对于这个问题实际上我不止一次提出，即技术人员特有的一种技术狂热主义。很多技术人员对新技术痴迷，同时有极强的自我主义。如果是引用别人的开源项目，总感觉体现不出自己的技术优越性，因此个人主观意识里面就是自己也开发一套性能或能力更加强大的。

　　这种思维还有一个重要的表象就是程序员自我的个人价值实现和利益考量。简单来说如果是自己手写了某个技术框架并大面积得到了使用，这个不仅仅是技术成就感的问题，同时也是自己能力的很好证明，可以更加方便自我价值实现，后续自我职业发展等。

　　但是这种个人价值驱动往往是有损组织级的利益的，比如常见的一种情况就是公司花钱结果程序员自己重复造轮子，搞自主研发和平台，技术人员自己能力提升后快速跳槽，给企业留下一个烂摊子的情况。

　　内部协同困难和敏捷性

　　为何一个大企业在各个不同的产品线内部也重复开发同样的东西而无法复用?

　　这个又不得不回到企业架构和组织壁垒方面的话题，不同的事业部开发相应的组件肯定是优先满足自己的业务场景和需求，但是这个组件如果要开放给其它事业部使用，那么就需要进一步的抽象和重构往往才能够满足。

　　对于提供者来说往往并不希望花这些成本费用去重构，而对于消费者来说也觉得提供组织本身的软件平台或组件无法满足自己的敏捷需求。

　　当无法形成一种跨事业部的横向协同和管控机制的时候，那么一定会出现在企业内部各个组织单元之间也不断重复造轮子的情况。也正是这个原因可以看到一些组织会将基础平台类的部门单独出来，同时强制要求其它产品线基于共性技术平台或组件构建上层应用。

　　企业本身的完全自主可控需求

　　还有一种重复造轮的的情况就是企业自身对于某一个基础软件，技术组件需要做到完全自主可控的需求。如果采用商用软件，那么软件企业本身不开放源代码，无法做到完全自主可控。如果采用开源的软件，那么软件本身存在哪些漏洞或风险实际上也是一个未知数，对于后续软件的版本升级等也无法很好的把控。

　　因此对于一些安全性和自主可控要求高的企业来说，仍然存在即使有主流的开源解决方案的情况下，也对某一个基础平台或技术组件重头进行自主研发，做到完全自主可控的情况。

　　在前面详细谈了重复造轮子存在的一些可能的原因。基于这些点分析可以看到，真正去重复造轮子的情况唯一就是自主研发可控，特别是一些基础软件和基础中间件上面。

　　类似我们看到的数据库，应用中间件，消息中间件等。

　　如果一个基础软件或基础库，当前只有商用的版本而且不开放源代码，那么为了做到完全的自主可控，你只能够是自主研发实现。

　　或者一个软件项目虽然有开源实现，但是根据开源协议要求，如果你在开源项目基础上做了变更或定制，对应的软件或产品也需要开源，这个可能也无法满足一些组织自主可控和安全管控的要求。

　　这两种情况往往都需要导致重复造轮子。

　　而对于前面谈的需求无法满足需要对开源软件进行适度定制，技术人员自身的技术狂热等都不是你重复造轮子的理由。

　　当在一个大企业或组织内部，你发现一个软件组件无法跨部门复用的时候，你就需要去解决这个问题，而不是各自为政都去搞一套，这将对后续软件应用的维护带来巨大影响。同时如果同一个技术组件，两种实现，本身也导致增加了人员学习负担和人员技能要求。这些本质都是无谓的成本投入和浪费。

　　

　　就拿远行科技我们自己的ESB总线产品研发来说，我们差不多是在2011年就启动了自主ESB服务总线的研发，当时采用去IOE架构，也没有基于任何开源的ESB产品，而是完全从头做起完成核心ESB总线的协议转换，代理，路由，日志监控等核心功能。

　　但是在14年我们废弃了这套ESB版本，其核心的原因就是自主研发当时仅仅是满足我们对外项目特定场景下的集成需求和管控要求，因此在底层架构本身的可扩展性，性能，支撑的适配器能力各个方面都存在不足。如果要基于这套ESB进行功能扩展，那么整体的研发资源和投入量将是巨大的。

　　

　　也正是这个原因我们进行了重新ESB产品规划和选型，最终选择了基于Camel规则引擎的ServiceMix开源ESB总线产品进行定制开发，即基于开源ESB产品定制开发设计工具，定制治理管控平台能力，底层引擎本身基于开源实现。

　　由于本身开发设计平台，管控平台和底层引擎之间本身就是一种松耦合的架构模式，因此对于ServiceMix本身的版本升级我们也基本可以做到平滑升级。

　　基于这种模式，我们既减少了在底层技术平台上的大量资源投入，同时又基于我们自己的SOA项目实施经验，扩展了覆盖服务全生命周期管理，覆盖SOA运维监控，管控治理要求的完整SOA开发设计平台和SOA管控治理平台。包括在后续的产品推广中，我们也完全说明底层基于哪个开源ESB产品进行的定制，同时强调差异化的竞争优势。

　　

　　而对于API网关，我们也基本采用类似的思路，即选择了Kong网关作为底层引擎，并扩展外围的API快速开发平台和Kong网关对接，同时定制开发API管控治理平台，通过Kong提供的标准API接口实现集成。

　　即站在巨人的肩膀上，集中优势资源去解决差异化竞争力，而不是重复造轮子。

　　今天写这篇文章，实际是突然发现一个问题，即各大互联网公司不断在自研自己的微服务开发框架，事件处理框架，消息中间件，微服务治理框架，服务注册中心等。比如这几天刚看到的消息微众开源的 EventMesh 进入Apache孵化项目。

　　为何各大互联网公司的软件团队如此的热衷自己造轮子？对于这点也欢迎大家讨论。