您的位置:首页 > 其它

新入手一个新系统,如何重构和梳理

2017-05-26 22:55 197 查看
难点, 对系统依赖理解变更.:

1. 变正向调用 为下游系统,传一个 id,然后通过这个 id 去查. (流水系统变存储为业务系统)

2. 两个流程拆分后. 至少会出现1.上游 – 边界转换类 – 2.下游支持接口.(业务无关.)

支付,业务计算的乘客支付数据payId和 clientPayParam 传递给转换成,然后在调用不同的渠道支付(phoenix,企业支付,第三方商户支付.)

有时候边界转换类可以变成集成类(属性+方法). xxxManager父类,含抽象属性. 各个实现类调用下面的具体渠道的 service.

manage 抽象父类,下含有抽象属性.

子类里才真正的将属性泛化,抽取具体的数据.

抽象父类+抽象属性是共同存在的. 这个是技巧+难点.

简化了父类create逻辑.

如何梳理?

1. 了解业务

2. 了解层次

3. 了解各个层次是否要关心这些 type 值.

代保养感觉都要重新写一套.各种并行的 type.没有很好的过滤掉.将上层业务区别下沉到了底层.就是为了方便统计.特别是state 和 payType.

哪些不合理. 层次,状态,类型?

如何整改这些不合理? 特别是影响到各种统计业务.对他们来说也是解放.

如何重构,如何兼容历史数据?

1.增加新字段,老字段不动.

新的业务都利用新字段判断.老字段只是插入和兼容大数据统计.

2.待新的业务变更时.通知大数据,让其修改对应的 sql. 因业务驱动修改.而不是重构而修改. 没做,只是影响了新业务.影响面小.

兼容老数据而做的妥协.
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: