代码阐释系统 从数据分析角度理解一个新系统

父文章 如何梳理和重构 含复杂性度量_个人渣记录仅为自己搜索用的博客-CSDN博客

外链: 

代码阐释系统 从数据分析角度理解一个新系统

新同学熟悉一个新系统 接手新业务_熟悉新系统总结怎么写_个人渣记录仅为自己搜索用的博客-CSDN博客

现在是从代码到数据到业务这个方向,存在字典跨层鸿沟

另外一个方向是 需求到代码自动化实现. 也可能会固化某些层次. 例如只会选择, 对象的组装,验证. 持久化这种路数. 而不是 验证,组装. 这种路数. 

数据层级 就是  实体关系. 例如 traceId 上挂 接口 和 日志. 

业务的层次

        下一层要依赖上一层的数据, 文本. ( 静态代码蕴含的概念 要 持久化到数据库中. 或者大数据中要有字典表, 这点是当前系统没有的点. 通过这个系统,层层递进理解系统. )  但是一段代码有没有取决于某个业务需求,例如要不要风控,要不要有个领域类uctOperation , 快速动态变化. 所以概要设计去维护这个字典数据,也有点难. 另外哪怕同一种业务,代码也可以不同的组织方式. 模板类, 先验,再组装,再事务(但是只要依赖了下游的rpc,这些努力都白费,下游的组装和调用都在rpc内.). 这些在数据报表的系统上都存在字典跨层鸿沟.

          2.1 边界层

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

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

          2.5 单测层
   

一次迁移梳理让我更深刻得认识到需要哪些数据.

大数据分析.

1. 静态的业务数据.

     业务表. pdCode,eventCode等.

2. 状态变更数据

     数据库的更新数据, before 和 after 还要有traceId 和 spanId

   可以用 DB的更新拦截器替代.

3. (系统视角,直接下游是谁,直接上游是谁)

     各个流量入口的 traceId ,接口, 上游系统, 对应参数. 下游系统接口,系统,参数.

      直接下游

             接口,含spi
                利用监控时序图(mass monitor as service )里的数据, 最好是天级的. 还需要依赖 系统的维表信息, 属于哪个域
             消息 

      直接上游

              利用时序图里的数据, 最好是天级的. 还需要依赖 系统的维表信息, 属于哪个域

      先有实时表然后在各个枚举值下抽样traceId保存.

   各个系统自行抽离维护枚举字段(最好是自动化生成的字典表),抽样率, 抽样后的数据. 客户端网关处枚举抽样很重要. 参数的格式也是统一的.

   大体上就能统计出有哪些业务, 这些业务有哪些流量入口. 每个状态机变更来源于哪些业务.

4. 基于代码覆盖率抽样决定traceId是否保存! 

    对于回归验证非常重要.
 

这两个系统意义非常的大

全链仿真-迁移用.

mock流量回放- 重构用.