一、问题布景

1.1 场景概述

  • 场景 A:运营活动项目,需求装备一些可动态调整的活动规矩;
  • 场景 B:信息展现页面,根据不同条件动态装备展现信息;
  • 场景 C:事务流程上的动态装备,如根据不同事务类型等条件装备商品上架参数等;
  • 场景 …N:……。
    比如以上的场景,在日常的开发作业中随处可见。咱们往往需求一个装备中心来完结事务功能上各种诉求的灵敏支撑。

    在转转公司,遍及运用的是携程开源的Apollo装备中心(以下简称阿波罗),而在实际的事务开发中,咱们遇到了如下的两类首要问题

1.2 危险问题

  • 前置要素 A:运营相关的动态装备往往需求由运营同学根据实时运营诉求不守时对装备进行修正和发布;
  • 前置要素 B:阿波罗的装备格局通常是运用 JSON 结构描绘的字符串,对运营同学有较高的学习了解本钱;
  • 前置要素 C:阿波罗装备的装备值信息,做不到根据结构化描绘下的字段校验,如:装备项格局校验、必填校验…等等。

    根据以上几点前置要素,在实际事务开发中,经常性地出现如下的首要危险点
  • 危险点 a:必填字段缺失,代码中没有对相应字段校验导致出现线上问题;
  • 危险点 b:字段格局过错,如:数字装备多写一个 1 导致数字范围溢出等等,然后引起线上问题或运营装备不收效;
  • 危险点 c:JSON 结构格局过错,多了或少了”{“、”]”、”,”、”\n”……种种的结构化格局描绘符或特殊符号,导致装备失效;
  • 危险点 d:短少细粒度的单装备项权限控制,多人并发更新导致实际装备成果不符合运营预期,大型活动开始前夕的大量装备发布行为更甚;
  • 危险点 e:开发同学需求对一切装备字段做详尽的繁琐的校验逻辑才能确保服务运行的安稳;
  • 危险点…n:……。

    比如此类的 CASE 还有许多,在此不作过多赘述。

1.3 功率问题

除了以上所描绘的危险问题,还存在一些影响功率的首要问题

  • 负责事务运营的同学需求一定的学习 JSON 结构的本钱;
  • 事务运营的同学需求较高的针对装备项的交流了解本钱,如”{aaa:1,bbb:333,ccc:[{c1:1,c2:2}]}”这样的装备值,并不能直观描绘其事务含义;
  • 对于负责项目开发的 RD 来说,作业中十分多的时间花费在帮忙别人了解装备含义上。例如:在项目开发进程中需求跟 QA、PM 同学重复同步;项目上线后,产品、运营同学往往需求每次更新装备都需求找对应 RD 同学重复承认装备规矩;随着相关人员的作业变动,相关运营装备规矩还得从代码层面重新了解拉齐认识

二、问题分析

2.1 以往的应对方法

以往的应对方法,首要有两种:

  1. 装备发布权限一致收拢到相关 RD,装备修正后由 RD 人工查验和发布更新。该方法在转转根底生态部门试行过一段时间,后因为影响装备修正的功率以及对 RD 形成的负担太重而没有长时间实施;
  2. 编写相关的装备文档。该方法在转转 B2C 事务部门长时间实施,针对每一个装备编写专门的操作手册,但对危险问题没有帮助,仅在功率问题上有较小的缓解效果。

2.2 首要矛盾点与问题实质的探究

2.2.1 首要矛盾点
  • RD 视角:期望沿用根据阿波罗的装备开发方法。首要含义在于开发提效,极大节省了装备后台开发本钱;
  • 运营视角:期望有完善的直观的图形装备后台视图。首要含义在于运营提效,极大的下降装备危险以及重复繁琐的了解交流本钱。

咱们发现:根据原本的装备开发方法,开发功率与运营功率好像站到了对立面。那么是否,真的鱼与熊掌不可兼得

2.2.2 问题实质的探究

回顾以往的应对方法,会发现现有的解法更多的是缓解问题而不是解决问题。曾经的方向更多是一定程度上在有限范围内接近目标而不是达成意图解决问题。

动态配置开发模式在转转的落地实践

如下图示意,将原本的装备相关的重复交流承认进程抽象为一种信息的传达进程,会发现问题可以描绘为:内容信息传达进程中的各环节的认知差与信息差导致终究内容的改变或丢掉

动态配置开发模式在转转的落地实践
信息源:本问题中指的是 RD 同学,装备的开发者。
*手信息接收者:本问题中指的是 QA、PM、运营等人物。

结合上述的思考进程,咱们企图通过一种清晰易懂的信息视图的出现方法:完结信息制作方与信息接受方在平等认知下的同频对话,借此避免认知差异以及信息的多次转述进程中的丢掉

三、方案设计

3.1 视图展现的规范化

如下图示意,提炼了从代码层面的装备信息到视图信息的规范化进程

动态配置开发模式在转转的落地实践

3.2 视图构建的自动化

首要,咱们认为视图构建中最初的根据是描绘视图确实定性结构化信息。从代码界说到终究的视图出现进程可以概括为一个规范流程:生成结构化信息-提取结构化信息-应用结构化信息。
所以,咱们期望通过自动化才能完结最大程度下降流程对人(开发者)的依赖,然后延续原先的高效开发体验(对开发者而言)。

3.3 开发体验的沉浸化

从开发者视角,期望保持原先根据 IDE 的开发体验不被打断,确保开发进程的接连

3.4 全体架构设计

动态配置开发模式在转转的落地实践

四、落地现状

该动态装备开发方案的通用版本已完结,完结 100% 掩盖原先的阿波罗装备开发场景。 在转转 B2C 事务部门应用近一年来 0 线上装备过错,同时避免了额外的比如编写文档之类的作业以及在装备规矩了解上的重复交流承认本钱

根据本方案,咱们延续原先的高效开发体验,即:

  1. 界说你的装备Key,如:smart_apo_config_test3
  2. 界说你的装备类结构,正常完结事务逻辑开发

框架将自动生成对应装备Key的视图,示例如下:

动态配置开发模式在转转的落地实践
动态配置开发模式在转转的落地实践

五、结语

本文侧重于介绍在作业中关于动态装备开发模式的演进进程,讲述了根据对问题的了解再了解的探究进程去寻觅当前最佳解决方案的思路,也是转转公司复仇者联盟技能生态系列之凯蒂组件的由来。


关于作者
陈奇恩,转转 B2C 事务供应链后端负责人。
转转复仇者联盟技能生态解决方案发起人之一。


> 转转研制中心及业界小伙伴们的技能学习交流平台,定期共享一线的实战经验及业界前沿的技能论题。

> 关注大众号「转转技能」(综合性)、「大转转FE」(专心于FE)、「转转QA」(专心于QA),更多干货实践,欢迎交流共享~