公司为何须要创建一套统一的开发框架？

1、原由：野蛮生长

近十年，中国互联网发展的速度愈来愈快，互联网科技颠覆了愈来愈多的传统行业，咱们的衣食住行随着互联网科技的进步，发生了翻天覆地的变化。在这个大潮中，愈来愈多新兴的公司如雨后春笋般的冒了出来，他们的业务增加很是快，公司规模也愈来愈大。这得益于中国经济的高速增加和互联网的快速发展。

弊端一：自我繁衍

在公司快速的发展过程当中，每每会出现这样一个链条。新增一块业务 —> 招聘一位高级技术人员 —> 围绕这位同事组建一只技术团队 —> 该业务基本由这只团队负责。而后就造成了一个闭环。当须要跟其余业务进行交互时，常常是技术负责人之间自行决定。（我曾经经历过一个项目，一样一个业务接口，同时提供 RPC，HTTP，MQ 等多种方式，为了给不一样的项目提供基础服务）。

弊端二：管控壁垒

随着业务规模的快速发展，这个团队很快的造成了一个部门，团队决策者一般会从自身利益考量，但愿尽可能减小对外部门的依赖，不管是技术选型，规范创建，组件选取，运行环境都可以自行掌控。（在这里讲一个笑话，在一家公司怎么成为中层领导呢？很简单，招聘足够多的下属就能够了）。

弊端三：断崖效应

当这样的技术氛围一旦造成，单个员工对单个项目的影响就会变的很是巨大。一个产品常常会由于一两个核心员工的离职难觉得继，最后不得不从新开发新的产品。

弊端四：资源浪费

当每一个团队都在试图构建本身完整的研发流程时。中间的技术研究，产品研发，运维管理就会出现很是多的资源浪费。

弊端五：难以考核

怎么衡量一个川菜厨师和一个鲁菜厨师谁更优秀？当每一个团队都采用不一样技术栈，不一样的技术组件，不一样的维护方式和规范时。已经没法从产出效率来判断一个团队的绩效。KPI 指标也就很是难以设立。

2、如何破解？

在公司发展初期，为了快速的进行业务拓展，大都不考虑成本投入，运营维护以及技术沉淀等问题。全部的指标导向都是业务的快速发展，尽量的抢占市场份额，获取足够多的用户数量。

在公司发展到必定阶段后，市场逐渐趋于稳定，先期快速扩展的各类问题会逐步暴露出来。从技术层面来说，若是能够造成公司级别的统一开发框架，会在实际的生产过程当中带来很是大的收益。

3、统一开发框架的优点

3.1 避免重复性技术研究——节约人力成本

让项目组把精力更多的投入到业务中。相信这是大多数技术公司的共识，若是让项目组把精力投入在业务中？就须要在项目组之下构建一个基础的开发架构平台，把技术的共性问题提炼出来，交给这样一个团队负责处理。避免每一个项目都独自去解决遇到的各类各样的技术难题，有效的把精力释放出来。

3.2 标准化技术规范——提高产品项目质量

要千人一面，而不要千人千面。采用统一的开发框架（平台）后，在技术栈，技术组件，技术实现方案，甚至在代码规范上就能造成标准化的技术输出模式，标准化带来的最大效果不只仅开发效率的快速提高，还有产品质量的大幅提高，这是显而易见的。

3.3 进行技术沉淀——提高公司总体技术能力，避免陷入一我的的能力决定一个项目

技术的进步来源于不断的技术积累和沉淀。每一个工程师都是站在别人肩膀上完成工做的。以项目为导向的技术团队，通常都会以实现业务需求为最重要的目标，技术只不过是完成业务的一种工具而已。基于此，业务开发团队就不可能把技术积累做为一项重要的工做。当一位核心员工构建了一些基础的平台工具后，每每随着他的离开把以前的技术积累所有丢弃掉，而更严重的状况会致使整个项目的持续运行都成了问题。

当存在公司级别的统一开发框架（平台），项目团队基于该平台进行自身项目的研发，再也不须要关注于底层技术实现，只须要关注业务便可。当存在核心同事离职时，平台的研发同事能够对新进入项目的同事进行相关培训，不会致使青黄不接的事情发生。并且，专一于平台的同事为了更好的知足项目组的技术需求，对平台进行不断的改进，从而达到技术积累和沉淀的目标。

3.4 可衡量的研发投入——对研发团队的有效管理和考核

当基于同一开发框架（平台）的标准化技术规范创建起来后，对业务功能的代码实现就能够进行相对有效的评估和考量，能够避免由于技术实现差别而出现的种种问题。这对 KPI 的制定和考核是一个巨大的帮助。

4、统一开发框架（平台）的定位和目标

统一开发框架（平台）定位于技术层面，其主要目的是为统一公司内相关产品研发和项目实施使用的技术架构和开发工具，有效提升统一技术支持力度，造成持续的技术积累手段，提高技术人员的利用率并下降对人员的依赖性，最终提高软件的规模化、流水线式的生产能力。

5、统一开发框架（平台）的建设思路

5.1 基于 Spring Cloud 技术栈

Spring Cloud 在 2017 年一跃成为最流行的微服务开发框架，不是采用了 Spring Cloud 框架就实现了微服务架构，具有了微服务架构的优点。正确的理解是使用 Spring Cloud 框架开发微服务架构的系统，使系统具有微服务架构的优点。下图为选择 Spring Cloud 做为技术栈的缘由。

5.3 部分 SpringCloud 构件的加强

Spring Cloud 提供的基础构建可能没法彻底知足业务需求，须要在部分构件之上作二次研发。好比咱们在 Zuul 基础之上研发的 API 网关、服务注册发现中心 EurekaPlus 等。

下图为服务注册发现中心 EurekaPlus 的截图，能够手动控制服务注册中心的节点状态，从而支持蓝绿部署。

5.3 新基础组件产品的研发

除了 Spring Cloud 的基础构件外，咱们每每须要开发新的基础组件产品来知足项目组的需求。特别是当前微服务架构大行其道，经常须要基于微服务架构的设计思想来开发新的组件产品，好比咱们开发的分布式任务调度框架。采用自动抓取，在线编排的模式，彻底契合于 Spring Cloud 技术栈。

下图为分布式任务调度框架原理。执行器在启动时将任务接口注册到分布式数据中心，编排中心从分布式数据中心获取执行器信息进行编排，而后把编排信息保存到数据存储中，调度中心从数据存储中获取信息对执行器进行远程调度。

6、统一开发框架（平台）团队的运做方式

如何在公司推动统一开发框架（平台）的建设，并非一件简单的事情。以我我的的经验，从分工和运做方式上来说，我主要着重把统一开发框架（平台）的工做分红三个部分。

开发示例、技术支持和技术规范。编写完整的开发示例，对不少新接触统一开发框架的同事来讲，有一份完成业务开发是很是重要，不只仅能够指导你如何进行业务代码的编写，同时还可以指导你如何编写出正确、高效的代码。还须要对不少同事进行技术培训与技术支持支持，都是统一开发框架（平台）团队应该完成的工做。

服务运维。统一开发框架（平台）提供了不少公司内部的服务，好比服务注册发现中心、配置中心、监控中心、链路中心、健康监测中心等。这些都须要统一开发框架（平台）团队进行运维。

新组件、新产品的研发。前一章节提到的 API 网关、分布式任务调度框架、服务注册中心 Plus 等。都是统一开发框架（平台）团队的工做范围。

7、过犹不及

虽然建设公司级的统一开发框架（平台）会在实际的生产过程当中带来很是大的收益。但未必适用于全部状况，考虑到某些项目产品的特殊性，并不能一律而论。

做者：梁鑫

来源：宜信技术学院