常见的项目复盘梳理。

总结学习，不断进步。

目录

使用 JVisualVM 分析 dump 文件定位 OOM 实战笔记

项目复盘梳理-02-旧系统数据迁移到新的系统

旧的产品线数据：

三大块：

（1）控台

商户、机具、服务商

（2）交易

（3）分润

新的 star 系统：

包含上面全部功能。

期望所有的数据从老系统迁移到新系统。

分步走的迁移策略

产品分布

为减低迁移风险，首先迁移一个最小的产品线 rpos。

数据继续切分

分步走：

（1）不切交易。只切基本数据。

首先正向迁移迁移基本信息，保障新控台保障所有旧的数据信息。

整体排期

【项目立项】：应用申请 + GITLAB + DevOps流水线 + 数据库资源 + 网关

【项目文档】：需求分析拆分 + 应用架构文档 + 接口文档 + 详细设计 + 微信技术调研

【开发实现】：UI 切图 + 前端实现 + 后端实现 

【联调】：后后端联调 + 前后端联调

【测试】：测试用例评审 + 接口测试 + 功能测试

【上线迭代】：微信域名等配置 + 微信菜单配置 + 关注回复等

类似于微信的开发者平台，一家公司要想做大做强，把自己的业务能力外放出去是必须的。

只有构建出自己强大的生态，才能永远屹立不倒。

核心模块

核心功能：

（1）请求类

用户可以主动查询，得到对应的结果。

（2）通知类

当一些事件发生的时候，通知用户。

（3）文件类

比如交易的对账文件。

一般是基于文件的形式，常见的方式有把文件放在对方 SFTP 服务器的。

其实比较好的方式，是让对方通过 appId/appSecret 自己去一个地方取，比如 OSS。

背景

客户可能会提起投诉。

以前都是通过邮件 + EXCEL的方式，不利于分析与流转。

整体功能

内控上传工单

1）首先进行工单的信息校验，判断是否合法，是否重复等等，把校验不通过的返回给页面。

PS：这个步骤是比较漫长的，不要让用户同步等待，而是后端异步处理。最后让运营可以再内控文件下载中心查看。

2）后端程序调用商户+服务商服务，把数据全部填充完成。状态初始化为 I

3）内控可以看到所有的工单，可以对工单进行审核/或者修改。

4）外控服务商，可以看到自己名下的单子。所有的流转日志，处理对应的工单信息，上传对应的材料等信息。

需要一个给用户培训的入口。

以前做过一个版本的操作手册，但是相对不是很满意。

是控台作为入口，说实在的不是很方便。

于是有了基于小程序的这一班需求，入口方便，便于用户使用。

设计

内部控台

可以再内部控台查看配置内容。

可以上传配置内容，定时发布，指定可见用户的类别。

用户类别：商户、代理、渠道。

发布时间：立刻发布、定时发布

内容分类：可以自定义分类

内容类别：图片、文章、视频、pdf 等

用户交互：阅读、点赞、收藏、查询

对于比较多的多的配置。

如果需要迁移，可以首先全量，然后增量。节约时间。

同样，配置的加载也是同样的道理。

可以初始化的时候，全量加载，然后定时增量加载。

要求

要求配置信息，必须要包含对应的 update_time。

拓展阅读

https://github.com/houbb/checksum

什么是代码本身的质量?

代码本身的质量: 包括复杂度, 重复率, 代码风格等。

复杂度: 项目代码量，模块大小，耦合度等重复率: 重复出现的代码区块占比，通常要求在5%以下(借助平台化工具如Sonar)代码风格: 代码风格是否统一(动态语言代码如JS, Python风格不受约束)

代码质量下降恶性循环

常见的代码质量下降的原因:

1. 破罐破摔: 在烂代码上迭代代码罪恶感比较小

2. 传染性: 不在意代码质量, 只关注业务的产出

3. 心有余而力不足