文章目录

• 老业务踩坑总结
• • 1. 改动老业务
  • 2. 需求说老业务只修改一个判断条件
  • 3. 新需求提出时遗漏的老规则校验

老业务踩坑总结

1. 改动老业务

• 需要确认所有端是否都影响
  • IM（实时通讯）、Android、IOS、H5、客户端新老版本、支撑部门、数据部门等
  • 因此需要了解端到端，站在项目经理的角度，通过整个项目的全局评估需求
• 实际业务案例
  • 新增一种礼物种类，关键是付费方式与老的礼物相反，其他流程基本一致
  • 发起方向接收方使用新礼物发起视频聊天，发起方收费、接收方付费
  • 以前所有逻辑都是发起方付费、接收方收费
  • 导致了支撑部门以及数据部门查视频聊数据库时有比较多改动，因为他们都是将发起方默认当作付费方

2. 需求说老业务只修改一个判断条件

• 为了快速上线，说老业务只修改一个判断条件
  • 首先确认老的业务实现是否正确
  • 其次新老版本如何处理
  • 然后是否改动会影响到其他模块
    • 由于老业务不符合单一职责原则
    • 为了快速开发上线没有遵守开闭原则
  • 最后就是非业务功能问题是否会出现
  • 这时就看出符合单一职责原则、让项目低耦合高内聚的好处
• 实际业务案例
  • 原规则是用户榜中在线的用户按照注册时间排序，改成 N 分钟内在线的未充值用户按照注册时间排序
  • 看似只需要将在线用户榜改成 N 分钟内在线的未充值用户，但是需要考虑：
    1. 并发量暴增导致高并发：榜单对我们的服务器来说算是高并发的榜单（TPS 高峰上千）、且数据一致性要求较高（不能使用 Redis 缓存或 MQ 异步），改动后还需要去二方的基础服务查询用户是否充值，因此 Java 端存缓存需要二方通知用户充值
    2. Redis 榜单 score 的选取：由于最终是按照注册时间先后来排序的，又需要满足 N 分钟在线且数据需要实时更新，因此要么做个每秒定时通知榜单的用户过期踢出，要么新加一个按照活跃时间排序的中间榜单
• 每一个老业务的改动都要特别小心谨慎，永远不要说一定，极可能会有其他意想不到的问题

3. 新需求提出时遗漏的老规则校验

• 新需求提出需要确认、是否需要校验系统已存在的公共规则，校验的顺序
• 实际业务案例
  • 新提出的需求多人交友，它与以后的直播类似，直播开播需要校验的公共规则
    • 配置下线
    • 处罚
    • 拉黑
    • 特殊用户（审核、运营人员）
    • 实名
    • 用户黑/白名单
  • 新提出送新类型礼物，它与老的送礼物类似，因此送礼前需要校验公共规则
    • 双方都需要
    • 处罚
    • 拉黑
    • 特殊用户（审核、运营人员）
    • 礼物类型
  • 新提出视频聊榜单，它与老的榜单类似，因此需要校验上榜公共规则
    • N 秒缓存优化
    • 封面
    • 视频流
    • 处罚
    • 用户黑/白名单
    • 拉黑
    • 特殊用户（审核、运营人员）