2023.2-2023.3 新贵族体系总结

背景

业务需求：将用户的贵族身份从【个人维度】转为【房间维度】。

参与开发人数：4

个人角色：核心开发（A角），负责主要流程的设计与开发。

原贵族等级是根据配置表的自增主键ID做排序，ID越大等级越高。对于这种设计，无法在原等级中间插入等级。只能在最前或最后增加等级（如果主键类型不允许为负数，也无法在最前增加等级）；
需要考虑新旧兼容问题，服务端接口需要区分客户端新/旧版本号，做不同处理。评估同一用户在一个时间段内来回切换新/旧版本产生的数据对于业务的影响范围；
在完全熟悉旧代码/业务逻辑之前，需要根据旧表设计新表。并且这些新表和旧表还有关联关系；
对于服务端和客户端现有代码，都是使用个人维度的贵族信息。而这些个人维度的贵族分析被十几个乃至几十个其它业务用到，都需要逐一经过“服务端开发、客户端开发、产品”对历史业务文档和代码逻辑反复研讨后才能决定如何修改（如何展现房间维度的贵族身份信息）。

核心逻辑包括：开通、续费、体验、升降级、冻结。这些核心逻辑的关联性强，而且是整个功能模块的基础，所以在时间充足的情况下由同一人实现是最理想的情况。但实际的需求周期较短，无法允许由同一个完成所有的核心逻辑。如何保证大家在同一设计思路下实现各自被分配的核心逻辑？
由于没有人熟悉以前的贵族业务代码，所以没人能较为准确地预算出这次改版所需的时间和人力，我们在开发的过程中逐步发现还有很多之前没想到的功能点需要确认和开发。在上线时间点被定死的情况下如何安排人力解决这些逐步被发现的功能点？

增加“权重”字段，用来代替主键ID的排序含义，使得表里每个字段尽量只有一个含义。这样，主键ID仅作为不同等级贵族的枚举值，而等级大小由权重决定。需要注意的是：权重避免设置1,2,3,4…这样的数字，可以用1000,2000,3000,4000…这样的数字。好处如果需要在等级1和2中间再插入等级，权重可以表示为1001/1010/1011等等；
因为服务端的接口需要根据APP版本号来存取旧/新表，所以需要评估自身的业务场景，当用户使用同一个账号在新/旧APP来回切换并产生的相关数据是否能够接受。我们评估自身业务场景后做出的方案是：在用户没有过使用新APP的情况下，允许一直使用旧APP。而一旦用过新APP后，再次登陆旧APP就会弹出强制更新弹窗，强制用户升级；
我们当前的做法是参考为一部分旧表创建了新表（大部分字段还是和旧表一样），还有部分旧表延续使用。虽然现在完成了业务需求，但如果当时为所有旧表都建一份新表，受旧表的业务含义限制就会更少；
因为没有人对历史代码很熟悉，这部分只能从代码涉及的业务范围，花时间跟多方确认修改方案。

在没有充足时间将新贵族体系所有功能模块的流程图都画出来的情况下，最起码要保证核心逻辑流程图能画出来。对于核心逻辑，必须要确保开发的人在同一设计思路下实现。而流程图正是为了保证这点而必须要完成的工作，而且最好是由负责人统一完成；
对剩余功能点进行拆分，增加开发人力。除此之外好像没有特别好的方式了，当前我们也是这么做的。

表里的每个字段尽量只有一个业务含义；
对于等级、权重这种有排序性的数值型字段，可以使用1000,2000,3000…这种位数较高的数，方便后面可以在中间插入数值；
对老功能进行改造前，思考是否需要处理新/旧兼容的问题；
如果是对整个老业务模块进行大改造，而且在表数量不多的情况下。可以考虑是否为全部旧表都建一份新表；
流程图绘制能力提升，以及绘制时间点的把握（对于关联性比较强、是业务核心逻辑、需要拆分出去给其他人一起做的功能，最好还是绘制）；
对于不大熟悉的业务，如果涉及到维度转换，需要评的时间需要多一点，而且可能需要中途增加人力的准备。因为假设尽管新增功能点不多，但是维度转换需要很多时间去和多方确认历史代码如何修改。