前端代码白盒依赖分析平台 + sdk

一、前言

控制修改引入问题一直是大部分公司产品迭代/项目研发过程中的痛点问题。修改引入问题的控制点寻找也是作为前端开发应该思考的问题。在拿到这个问题后，进行了简单的思考。

二、分析

当前开发问题拦截流程

可以发现，如果开发对修改场景不熟悉，自测试又不够充分，能够拦截引入问题的流程，只有代码审核人、门禁和DT自动化测试；

• 代码审核人：我天天要合几十个MR，又没法实时测试，光看代码让我看出引入问题，啥事都不干了？
• 门禁：我很傻，只能检查检查编译问题。
• 自动化测试：我很牛，我能覆盖所有引入问题。但是你要花一年时间给我开发所有用例，覆盖一个产品/项目的所有场景。

这就是我们项目现状。我们属于前端项目团队，DT界面自动化测试刚起步，不可能覆盖所有场景；前端代码每次提交量大，光看代码不调试很难看出问题；面临问题流入后端多，改一个问题引入两个问题的痛点；

添加一个新流程

在分析上述原始流程后，觉得问题出在对于引入问题的检测，局限在人工检视层面，缺少自动化扫描工具；

是否可以通过一种方式，能够自动检查修改是否会引入问题？这里我想到了场景管理关系管理：

即场景库管理。

如图，开发通过确定自己修改的场景去场景库中寻找与场景关联的关联场景，然后再确认这些关联场景有没有覆盖到，将检查结果附在问题单走单环境，作为走到测试前的一道新拦截保障；

三、确定方案

按照上述想法，我决定带团队做一个简单的场景库管理系统；由我负责使用nodejs编写后台及数据库相关的代码，提供场景库管理API；由同事负责前端人机交互页面的开发；

可想而知，整个流程修改需要完成需要3个步骤；

• 1、场景库管理系统开发（提供场景增、删、改、查及维护场景间关联关系）
• 2、场景库输入
• 3、输入场景关联关系
• 4、开发访问系统获取场景关联关系，截图确认

程序员出生，急于做技术的我，立即动手开干，3天时间搞完了第一步场景库管理系统的开发；然后到场景库输入和维护场景关联关系的时候，我犯了难：

• 1、场景很多，我按照什么维度梳理？
• 2、每种场景关联关系复杂，关联关系巨大，谁有能力去维护？
• 3、开发修改的代码，怎么知道影响了哪个场景？
• 4、…

当我对着只有零星几条测试场景的场景库管理系统的时候，树状结构的场景库引起了我的灵感：

修改的东西是什么？是代码文件！代码文件就是树状的结构！如果我通过修改的代码文件，就能推断出可能受到影响的文件，岂不是回归了从代码修改到代码影响确认的端到端验证的本质?

而且，代码修改的文件，本身就在提交MR流程中可以获取，如果能实现自动化分析，那将极大提高影响的分析的精准性和效率；现在问题就一个，如何分析代码文件的依赖关系？

对于前端来说

这对于写前端的同事而言怕是不是什么大问题了，了解 AST和bable的同事们自然清楚，通过 @babel/parser 提供的工具，可以分析代码语法树，从而得知代码依赖关系，再从依赖关系映射到具体物理文件：