如何梳理和重构 含复杂性度量

父文章   如何写可维护的代码 - 万物ddd ddd primitive . 封装,对象来实现可维护代码._个人渣记录仅为自己搜索用的博客-CSDN博客_ddd 代码demo

相关文章    交易系统模块划分,模块拆分,设计,重构实战.状态_个人渣记录仅为自己搜索用的博客-CSDN博客_系统模块划分案例

程序复杂性度量?

    两个度量值? 字段数, 字段的调用路径数(从本系统的最外层facade入口算起). 举个例子, 一个系统有各种各样的订单. 然后就抽象出一个BaseOrder.

public class BaseOrder{

String status;

}

静态表面上看是一种很好的抽象, 只有一个字段. 且状态值也就三个.  但是你会发现,不同的业务有不同的status. 调用的入口会非常得多.  这个时候就需要重构,每个业务的status字段,各自维护.

内存中的领域类 

 !=自己系统的表而是 = 自己系统的表+下游接口的字段+透传字段.

程序=

   字段 + 流程 + 状态 (约束,异常,核对)  人人都是好的软件开发设计师_个人渣记录仅为自己搜索用的博客-CSDN博客

 

  

本文较细,较散. 没有方法论结构化.


      

如何梳理?

   1. 了解业务?

         1.1 BI报表, 支持阅读端下钻能力的报表 (交叉表支持的新能力)

           各种维度,结合自己整理的字典表 + 两码字典表- 对应产品经理. 快速咨询,了解业务.   

           详见  接手新系统 接收新业务  数据了解一个系统，

     2. 了解业务层次 (静态)

        下一层要依赖上一层的数据, 文本. ( 静态代码蕴含的概念 要 持久化到数据库中. 或者大数据中要有字典表, 这点是当前系统没有的点. 通过这个系统,层层递进理解系统. ) 

          2.1 边界层

          2.2 用例层
          2.3. 活动图 状态机层

          2.4 技术层面了解业务-   代码阐释系统 从数据分析角度理解一个新系统_个人渣记录仅为自己搜索用的博客-CSDN博客

          2.5 单测层
      3. 了解各个层次是否要关心这些 type 值.
    代保养感觉都要重新写一套.各种并行的 type.没有很好的过滤掉.将上层业务区别下沉到了底层.就是为了方便统计.特别是state 和 payType.(类似 四码 ,pdCode)
    哪些不合理. 层次,状态,类型?
    如何整改这些不合理? 特别是影响到各种统计业务.对他们来说也是解放.

如何重构?

  (分拆上沉/下浮)/归纳/分层

   大的架构模型有

     支撑组合结构 (平台) + 引擎回调结构(固化流程, 增加spi回调, 同时使上游的分叉减少,减少这部分人力和组织. 但同时可变性较少. 无法引入商户等. 中台 适合demo 前期, 需要考虑好odps权限统计的问题. 订单Id 先都查,后期数据迁移后,删掉远程查询).

  如何兼容历史数据?

  1.增加新字段,老字段不动.
         新的业务都利用新字段判断.老字段只是插入和兼容大数据统计.
      2.待新的业务变更时.通知大数据,让其修改对应的 sql. 因业务驱动修改.而不是重构而修改. 没做,只是影响了新业务.影响面小

         兼容老数据而做的妥协.

         新接口调用老数据，老接口调用新数据。

         

对系统依赖理解变更.: 
   

 1. 变正向调用 为下游系统,传一个 id,然后通过这个 id 去查. (流水系统变存储为业务系统)
    
 2. 两个流程拆分后. 至少会出现 1.上游 -- 边界转换类 -- 2.下游支持接口.(业务无关.)
       支付,业务计算的乘客支付数据payId和 clientPayParam 传递给转换成,然后在调用不同的渠道支付(phoenix,企业支付,第三方商户支付.) 
       有时候边界转换类可以变成集成类(属性+方法). xxxManager父类,含抽象属性. 各个实现类调用下面的具体渠道的 service.
        manage 抽象父类,下含有抽象属性.
        子类里才真正的将属性泛化,抽取具体的数据.
        抽象父类+抽象属性是共同存在的. 这个是技巧+难点.
        **简化了父类create逻辑.**
        

 4. 有的数据可以通过 result 返回. 而不是上游先算出再下传(减少计算所需的业务知识) 
     例如支付的金额中 乘客余额支付的金额,乘客支付宝支付的金额.券支付的金额.
     原业务系统,这块的计算都放在 bill 里面的. 对接北京后,就需要把这块逻辑抽出来.然后传递到北京.由北京计算实际金额. 然后回传给业务方.. bill模块的下沉
     **故支付里的支付数据可能是多次计算得到的.**