Vue前端调用链影响变更分析之一
- 一、背景
- 二、工具调研
- 1、 工具介绍：
- 2、工具使用
- 三、工具落地集成方案（待后续补充）
- 变更影响较为简单的实现
- 变更影响较为复杂的实现
- 1、全局关系数据库的构建
- 2、变更影响的简单实现
- 3、变更影响的复杂实现
一、背景
去年做了Java的后端调用链影响评估，但是随着项目迭代越来越快，评估影响也越来越难以满足用户需求，主要有以下几个原因：
1、项目迭代越来越快，有些项目接口都不测试了，接口影响评估被忽略了，用户更期望接口影响了哪些页面
2、老板更关注页面的交互，测试重心偏向前端的交互
3、前端外放Bug相对于后端Bug多太多了，测试选择性忽略后端的评估影响
快手在MTSC精准测试分享会提过，前端（客户端）的精准测试相较于后端而言，具有更广泛的受益，更值得去研究。从当前的经验来说，前端的精准测试确实更具有性价比。
二、工具调研
公司前端项目主要基于Vue框架进行开发。查阅大量资料后，对于Vue项目，dependency-cruiser这款工具获更被广泛推荐。
1、 工具介绍：
git地址
特性介绍：
1、可以根据自己的规则去匹配生成调用链
2、可以生成调用链图片
3、可以自定义输出生成的结果，比如json，text等
4、支持命令行规划
特性介绍：
1、自定义规则生成调用链：允许用户根据自定义规则，灵活匹配并生成调用链。
2、可视化调用链图片输出：提供直观易懂的调用链图片展示，便于快速理解和分析项目中的依赖关系。
3、多样化输出格式：支持将生成的调用链结果以多种格式输出，包括json、text等，方便用户根据需要进行数据处理和展示。
4、命令行操作支持：提供命令行规划功能，用户可以通过命令行轻松执行调用链的生成和分析操作，也方便后续工具集成。
2、工具使用
切换到项目代码路径下，安装
npm install --save-dev dependency-cruiser
# or
yarn add -D dependency-cruiser
pnpm add -D dependency-cruiser
注意：nodejs版本需要大于等于20
生成配置
npx depcruise --init
生成页面的调用链
npx depcruise src --focus "^src" --output-type text >vue_depency.text
生成结果如下：
src/App.vue → @/composables/useVersionUpdate
src/App.vue → node_modules/ant-design-vue/lib/index.js
src/App.vue → node_modules/ant-design-vue/es/locale/zh_CN.js
src/api/baseConfig.js → @/xhr/index
src/api/clientManagement.js → @/xhr/index
src/api/common.js → @/xhr/index
src/api/cooperateInfo.js → @/xhr/index
src/api/financeProfit.js → @/xhr/index
src/api/financeRules.js → @/xhr/index
查某个组件的调用关系
cat vue_depency.text | grep editGmv.vue
src/screens/newStart/index.vue → @/screens/start/components/detail/editGmv.vue
src/screens/start/components/detail/editGmv.vue → @/api
src/screens/start/components/detail/editGmv.vue → node_modules/ant-design-vue/lib/index.js
src/screens/start/components/detail/editGmv.vue → node_modules/vue/dist/vue.d.mts
src/screens/start/components/detail/top.vue → src/screens/start/components/detail/editGmv.vue
从上面的图可以看到edit编辑组件被index、top组件调用了。->调用
可以加个参数过滤–exclude，node_modules模块的调用关系
npx depcruise src --focus "^src" --exclude node_modules --output-type text >vue_depency.text
三、工具落地集成方案（待后续补充）
1、跟后端一样，构建数据模型，通过neo4j图数据建立全局关系数据库，这样就可以通过模块查询影响的变更模块。
变更影响较为简单的实现
2、通过git diff 变更代码分析出变更文件，直接查询图数据库返回变更的影响模块范围，这个范围就很大。
变更影响较为复杂的实现
3、通过git diff 析出文件具体哪些行号变更，结合AST生成语法树，分析模块的语法数结构，结合变更行号，分析影响到了具体的某个组件。
4、分析样式变更影响范围
5、端到端的影响变更，后端接口可以分析影响变更的接口，通过接口反查页面调用情况，从而分析出接口的影响到的页面。
当然3、4、5下面两种情况实现起来比较复杂，目前还没有好的工具可以解决，期望实现的大佬可以指教下
大概的方案实现如下：
1、全局关系数据库的构建
与后端相似，先构建了数据模型，并利用neo4j图数据库建立了全局关系数据库，通过查询就可以快速识别并定位到变更所影响的模块。
2、变更影响的简单实现
利用git diff分析变更代码，从而识别出发生变更的文件。通过直接查询图数据库，能够迅速获取这些变更文件所影响的模块范围。这种方法较为简单，也容易落地，但所返回的影响模块范围较为宽泛。
3、变更影响的复杂实现
3.1、为了更精确地分析变更影响，需要进一步通过git diff细化到具体变更的行号。结合抽象语法树（AST）生成技术，分析模块的语法数结构，并结合变更行号，精确到具体影响了哪些组件。
3.2、补充样式变更影响范围分析。
3.3、端到端的影响变更，分析后端接口变更对前端页面的影响。通过接口反查页面调用情况，分析出接口变更所影响的页面，从而提供更全面的前后端变更影响分析。
当然，目前第三点的实现，有较大的技术挑战，尚未有成熟的工具能够完美解决，期望有实现的大佬可以分享分享
