跨语言重构踩坑之旅1

Posted on 2021-12-21 10:50  FLGB  阅读(98)  评论(0编辑  收藏  举报

重构直播项目背景:
1、php语言编写系统
2、该直播项目需要用到第三方声网服务
3、业务迭代了很多般,业务模块设计较差,业务功能杂乱
4、原php项目对应开发人员全部离职
5、产品本身对原有功能逻辑也不熟,但业务还在迭代更新,抽调其他组php去进行业务迭代更新
6、原项目表采用mongo表

人力资源:Java开发4 php转java开发2 前端3

java语言进行重构:
给出的重构方案:
总体目标:重构一期为实现后台菜单的重构,保留原有功能,保持c端接口不变,数据需要进行mysql结构化存储,老的直播能在新的直播系统中正常使用
实行结果中的疑难点:1、产品给出的原型图只有页面UI,没有功能交互逻辑,java开发照着功能页面进行表结构设计,缺少原功能接口内部逻辑可能会导致功能逻辑遗漏
(如果php开发每个接口去梳理,工作量巨大,而且php开发有对应的功能开发工作)
2、对接声望服务逻辑需要php重新梳理,在什么功能里掺杂了对声网的什么交互
3、新业务的迭代们需要不断在重构里增加修改功能逻辑
4、最困难的点(新老功能字段拆分对应,数据迁移问题),老的数据表是mongo表,缺少必要字段,需要根据每个接口梳理字段,对应到mysql结构化字段中,但是java无法梳理原有接口逻辑,php开发承担的化业务量过重;
5、数据迁移,梳理好字段对应关系,进行老数据迁移,一是首先进行全量数据迁移。但是c端不动,导致部分数据会落到老数据库mongo中,会导致数据库数据在c端的数据不一致,需要mongo增量数据到mysql;
另外新后台中创建直播,老版本的App也无法看到,需要mysql再增量到mongo对应表中。
整体方案进展,原定一个月开发时间,后延期至一个半月,仍卡点在各个点上,导致前后端连基本联调都不通。总体阻塞点非常高,基本确定方案实行不通,重构代价过于复杂、沉重

重新设计方案:
1、重构直播项目,功能最简原则,满足基本的直播开播需求,后台C端一起重构,总体工作量适中。数据方面直接做隔离,老的在老系统中看,新的直播在新的系统里面配置。
老的在老系统里正常迭代功能,新的项目小步快跑迭代,直接做最新的功能,最终达到新老功能的一致性。
前端页面显示一致性问题,可以由c端接口做聚合操作,等半年后在下线老系统半年前的直播(也可以一年后下线)

Copyright © 2024 FLGB
Powered by .NET 8.0 on Kubernetes