代码影响范围工具探索
作者：京东零售 田创新、耿蕾
一、背景
1.祖传代码不敢随意改动，影响范围无法评估。并且组内时常有因为修改了某块代码，导致其他业务受到影响，产生 bug，影响生产。
2.研发提测完成后，测试进入测试后经常会向研发询问本次需求改动影响范围，以此来确定测试用例，以达到精准测试，提升整个需求的质量，缩短交付周期。
那么，如何才能规避这种隐患？有没有一种工具能够协助代码研发及 review 人员更加精确的判断当前代码改动影响范围，有没有一种方法能够提供除了业务逻辑条件验证，针对代码作用范围，给测试人员提供精确验证链路？
二、方案调研
技术方案调研
经过各方资料查找及比对，最终我们整理了两个满足我们需求的方案：
1.IDEA 提供了显示调用指定 Java 方法向上的完整调用链的功能，可以通过“Navigate -> Call Hierarchy”菜单(快捷键：control+option+H)使用，缺点是并没有向下的调用链生成。
2.开源框架调研：wala/soot 静态代码分析工具。
针对上述的调研，大致确认了两种方案，集中分析两种方案的优劣，来制定符合我们目前情况的方案：
经过前期的比较以及相关工具的资料调研、工具功能分析，并考虑到后期一些个性化功能定制开发，以上工具不太满足我们目前的需求，所以决定自己动手，丰衣足食，尝试重新开发一个能够满足我们需求的工具，来协助研发以及测试人员。
三、方案制定
预期：工具尽量满足全自动化，研发只需要接入即可，减少研发参与，提升整个调用链展示和测试的效率。并且调用链路应该在研发打包的过程中触发，然后将数据上传至服务端，生成调用链路图。
上述方案制定完成后，需要进一步确认实现步骤。前期我们确认了工具的大概的方向，并进行步骤分解，根据具体的功能将整个工具拆分成六个步骤
1.确认修改代码位置（行号）。与 git 代码管理关联，能够使用 git 命令，去提取研发最近一次提交代码的有变动的代码行数。
2.根据步骤 1 确认收集到影响的类+方法名+类变量。
3.根据 2 中确认的类+方法名称生成向上和向上的调用链。包括 jar/aar 包。
4.根据 3 中生成的调用链完成流程图的展示。
5.自定义注释标签 Tag 说明当前业务，并提取 Tag 内容。
6.本地数据生成并上传服务端生成调用流程图。
整体流程图如下：
四、方案实施
1.定位源代码修改位置行号。
首先我们使用 git diff --unified=0 --diff-filter=d HEAD~1 HEAD 命令 输出最近一次提交修改的内容，且已只 git diff 会按照固定格式输出。
通过提交增、删、改的修改，执行 git diff 命令，对输出内容进行观察。
举例：某次提交修改了两个文件，如下
RecommendVideoManager.java
ScrollDispatchHelper.java
git diff 命令执行后，输出以下内容：
技术方案：
a.按行读取输出内容，读取到到 diff 行，则识别为一个新的文件，并用正则表达式提取文件名 ：
b.用正则表达式提取 @@ -149 +148,0 @@ ，用来解析代码修改行数:
c.针对我们的需求，我们只关心本次修改影响的是那个方法，不关心具体影响了哪些行数，所以我们只需要
就拿到了本次修改，修改开始的代码行数, 在结合 ASM 就可以获取到本次改动影响的具体方法。
2.利用获取的行号定位具体的方法。
根据上述 1 步骤中定位出研发每次提交的修改的 Java 源文件和改动的行号位置，我们需要定位修改代码行号所归属的方法名称，再由方法名称+类名+包名去定位本次修改的影响链路。
如何去定位？
首先确定的是，研发在工程中只能修改的是工程中的源文件，所以我们可以在遍历收集整个工程的源文件的过程中根据已知的修改行号来确定修改的方法名称，进而知道整个方法的调用链路。而对对于那些没有落到方法体范围之内的行号，基本上可以确认为类变量或常量，考虑到对于常量修改也可能影响到业务逻辑，所以我们也会对修改的 Field 进行上下调用的范围的查找，所以需要记录。所以整个过程分成两个部分：
a.遍历源码 Class 文件，获取整个类的 Field；
b.遍历 Class 文件的过程中，通过 visitMethod 遍历整个方法体，记录方法的初始行号和结束行号，来定位方法；
首先是 a 部分，确认 Field，ClassVisitor 提供现成的方法：
所以我们可以在文件中直接获得整个类的 Field。然后去根据行数去判断是否有对 Fields 有修改。如果 Fields 有修改，那么我们可以根据上述方法去比对，那么就可以获得哪个 Field 被修改。
接下来是 b 部分，在遍历 Class 文件的过程中，通过 visitMethod 方法，重写 AdviceAdapter 类来提供 MethodVisitor，在遍历过程中，完确定研发修改影响的类及方法，具体实现可分为以下步骤：
2.1 获取源文件编译好的 Class 文件；
apk 的编译过程中有很多的 task 需要执行，各个任务环环相扣有序的执行，我们要获取编译好的 Class 文件，需要在特定的任务之间。我们知道在 Java Compiler 之后，不管是 R.java 抑或是 aidl，再或者是 Java interfaces 都会编译成.class 文件，在编译完成后会接着完成 dex 的编译，所以我们尽可能的在 dex 编译之前完成 class 文件的处理，这种仅仅是考虑到宿主或者单独的插件工程方案，但是对于主站业务来说，会有各种各样的组件 aar，aar 的编译编译不会走 dex 编译，所以针对这些组件工程，我们也需要考虑到，简单的方式就是我们去监听 aar 编译的 task，然后再做一些处理，所以在 Plugin 的 apply 方法中需要进行区分处理，代码如下：
两者的处理逻辑一致，也就是在 Task 的监听有些区别，所以下面我们不重复复述，以 MethodTransform 为主线进行讲解。
那有的同学就问了，为啥我们不直接对源文件.java 文件进行处理呢？
因为，就目前京东主站项目而言，各个 aar 模块相互调用，如果我们仅仅使用源文件进行扫描，各个 aar 或者 jar 包的调用链会断掉不全面，影响代码 review 人员及测试人员的测试用例完整度。
接下来是代码实现，我们监听任务执行，并针对需要监听的任务开展我们的 Class 收集操作：
2.2 排除非 class 文件的干扰，对源文件路径进行递归遍历；
代码的编译长短对研发的影响很大，所以编译时长很宝贵，需要我们尽量的减少编译的时长，所以我们在执行我们自定义的 Transform 过程中，需要过滤并排除非 Class 文件，减少不必要的浪费。经过整理主要为：R 文件以及 R 文件的内部类 Rstring、R*文件过滤。
2.3 提供 ClassVisitor 类和 MethodClass 去搜集 Class 及对应 Method，并定位
这个步骤是最主要的一部分，这一部分主要获取两部分数据，第一部分是研发修改直接影响到的类和方法；第二部分是遍历整个源文件的所获得的类信息，主要包括类+各个方法以及各个方法体，也就是方法中的指令；
在拿到 transformInvocation 后我们进行源文件文件夹遍历和所有 jar 包的遍历，在外层我们定义好存储被影响的类列表（changedClassesList），和包含类信息的列表（classesInfoList），将两个列表作为参数，传递进去在遍历过程中赋值。这里值得注意的是，在进行 jar 解析过程中不需要进行 changedClassesList，因为对于本工程来说研发人员不会直接对 jar 文件中文件操作。
在对源文件遍历过程中，我们进行定位搜寻。
遍历源文件根节点并读取：
重写 ClassVisitor，ASM 提供的 visit 方法可以很方便的去识别这个类的各种信息，而我们用到的信息为两种，一种是接口类型的判定，一种是当前类的类名。对于接口，我们没有必要去进行 Method 的访问，对获得的类名信息我们进行判定当前类是否是 git 最后提交有做过修改的的类：
`在上述的 visit 中我们定位了当前类是否与上次 git 提交的是否有关，接下来我们需要 MethodVisitor 中进行有选择的拦截对应的 Method 的访问。
重写 MethodVisitor 在 visitMethod 中进行拦截处理，如果 git 修改相关在当前类中，则我们在访问 Method 时，进行方法体行数定位。
在 MethodVisitor 中，我们可以通过系统方法定位访问方法的每条方法指令及指令对应的行数，所以我们只要重写 visitLineNumber 方法即可实时的在 visitMethodInsn 方法中拿到方法体访问行数，这里有个小的注意点就是，我们在调用 visitLineNumber 返回的 line 不是我们理解意义上的方法名称部分开始，而是从方法体的第一行代码计算开始，所以我们在做判断的时候，需要注意，相对方法体的首行，我们更关心方法体的变更，所以我们只需要判定落在 visitMethodInsn 中的更改即可。有需要更加精细的判定，小伙伴可以进行更加精细的调研。
以下是 visitLineNumber 方法：
知道了方法体开始的地方，我们也需要知道结束的位置，获取到结束位置后，我们就能轻松的定位到我们需要的定位的方法体，从而获得方法名称，进一步获得类的名称。ASM 在 MethodVisitor 中提供了 visitEnd 方法，表示方法体访问结束，那么我们就可以在 visitEnd 中进行定位：
至此，我们通过自定义 ClassVisitor 和 MethodVisitor 完成了对源文件的搜集和定位。
总结一下思路：首先我们拉取了研发最后一次在 Git 上提交的代码，通过分析并找出规律，配合正则表达式匹配的方式，拿到修改的后缀为 java 的文件，又进一步的寻找规律筛选出对应 java 文件修改的行号；其次遍历工程源文件，利用自定义 ClassVisitor 和 MethodVisitor 进行类信息的收集包括类名、方法以及方法体指令，并在访问过程中提交后有修改痕迹的文件通过行号进行定位；最后完成收集集合的填充。这整个过程中用到很多比较重要方法，比如：CLassVisitor 中的 visit、visitMethod、visitEnd，以及 MethodVisitor 中的 visitLineNumber、visitMethodInsn、visitEnd 等。
3.遍历查找对应方法的上行链路和下行链路
在二步骤中完成了定位类与方法，并且完成了整个工程的源文件遍历收集，接下来就能逐步的整理出来，修改方法在整个工程中所带来的影响，
3.1 方法上行链路数据生成；
这一步骤相对来说比较简单，对于在上一步骤中，我们得到的上次的 git 提交定位数据，及整个工程的源文件类中方法信息的集合，我们只需要将改变的 list 集合在工程源文件信息集合递归循环，便能得到对应方法的上行调用链。而遍历的思路则是，递归向上扫描调用了变更集合中的类以及方法，以此递归循环遍历，只要调用到相关联的方法就被收集，对于 Android 应用来说，研发所写业务逻辑，基本上终止于 Activity 或者 Applicantion 中，所以向上的是有终点的。
如下是一个简图：
3.2 方法下行链路数据生成；
方法的下行链路相比上行链路来说更为分散，需要我们去定位变更方法体中所有的指令，也就是扫描方法体，以及方法体各个指令的上行链路，并且在日常的开发过程中，我们的方法中有很大一部分调用的系统 API，所以下行链路的扫描对比上行链路更为复杂。而对于研发或者测试，系统的 API 可能对我们的影响较小，所以在扫描下行链路的过程中，我们需要去识别当前方法体指令是否为系统 API。
在识别去除系统 API 后，剩下的即是我们的业务逻辑方法，那么又回到了方法体中各个指令的上行链路扫描，方法跟上行链路一致。
对于系统的 API 以及一些三方库，我们大致总结了一下几种，供大家参考：
示意图如下：
至此，我们完成了方法上/下行链路的搜索。
4.注释及自定义 Tag
上面三个步骤，我们们完成了对应方法上/下行链路功能开发，但是整条链路上只是包含了对应的类名+方法名，对于研发来讲，对应的类的作用以及方法的实现是什么逻辑比较清楚，但是仅仅局限于研发，对于测试人员可能没什么用，也只是一堆代码而已。针对这一问题，我们想到了注释，各个研发组在很早之前就开始接入京东自研的 EOS 来规范代码的注释，经过这么长时间的打磨也趋于完善。我们可以通过注释的方式来与对应的业务逻辑。我们设想能够通过某些手段去完成注释的获取，但是，注释可能也不能完全的去表达当前的业务逻辑，我们还需要提供具体的业务逻辑标注。
怎么解决呢？其实，总结起来就是，我们要说明上/下行链路涉及到的类和方法解释以及业务说明，并且可以利用一些特殊的标记去完成对应的一些特殊逻辑说明。
基于代码的注释，我们可以很容易的想到 JavaDoc，包括 Android 的开发环境 Android studio 中也自带了可以生成源文件的 javadoc（路径：Tools-->Generate JavaDoc），执行命令后几秒钟后，生成了一份完整的文档。
既然自带的工具可以完成 Java 文件注释的提取，那么我们也可以在代码中获取到对应的注释，经过相关资料，了解到，JDK 中自带的 tools.jar 包可以完成 JavaDoc 的提取。
在将 tools 包上传 Maven 后在 gradle 中进行依赖，基本就完成了环境的配置。经过多方资料的查找及 demo 实验，tools 包支持命令的形式生 JavaDoc。这里需要注意的是，我们不需要 html 形式的 javadoc 文档形式，所以需要进行一些自定义的东西来达到我们自己的要求。
官方文档是这样说的：
If you run javadoc without the -doclet command-line option, it will default to the standard doclet to produce HTML-format API documentation.
也就说，我们需要在命令行中添加 -doclet 来进行自定义文档。并且给出自定义的 Doclet 类：
接下来简单的封装 tools 中的 execute 方法：
其中命令中参数，感兴趣的小伙伴可以查看官方文档，这里就不再赘述了。
基本封装完成后，就可以直接使用了，但是考虑到在遍历使用的过程中会出现多次调用解析 ClassDoc 的问题，这里还是建议将解析过的 Java 文件进行缓存处理，方便直接调用，也能减少整个编译的时间，并且在解析过程中我们也需要排除系统类的解析。
这里我们也给出自定义 Tag，当然，在项目中可以根据自己的业务名称进行命名。
完成了功能的开发，我们需要在代码中中进行验证，测试如下：
当我们的方法调用链涉及到 getPrintMethod()时，就会提取 @LogicIntroduce 标签后面的内容，达到了获取业务逻辑说明注释的目的。这样对于那些不动代码的非研发人员，也能够非常清晰的看懂这部分代码涉及到的业务逻辑，测试也能够着重的进行测试了。
本地输出：
5.推荐实际业务使用
方法的调用上下链路在上述步骤中已经生成，我们可以在 MarkDown 中简单的生成调用链，至于要遵循什么样的格式，大家可以自己查阅，相对比较简单不再展开。下面是推荐位最近一次修改涉及到的部分流程图：
代码修改位置输出为：
向上调用链展示：
向下调用链，我们只取本方法体：
相关 Javadoc 输出：
五、总结
经过上面的描述，我们整体上完成了再 Android 端的代码影响范围工具探索，过程中完成了 Git 定位，生成方法调用的上、下链路，以及通过 JDK 工具 jar 包完成注释以及自定义 Tag 的内容获取，也通过 MarkDown 生成了对应的流程图。下面是整个工程的流程说明图：
对于这个工具来说，我们仅仅是对 Android 客户端的探索开发，目前已在推荐组进行试用，使用过程中还有一些问题以及流程需要进一步改善和优化，比如，当一个方法被多处调用则生成的关系图就会过去庞大，不容易被阅读；无法突出调用链节点的一些关键节点；JavaDoc 强依赖于研发，如果注释不规范或者不写，那整个链路的说明就会断掉等等，我们会持续性的去优化打磨这个工具，也会在使用过程中添加一些更贴近业务的功能，或者调整部分流程，比如说会在本地编译触发或者手动触发，或者添加一些 JavaDoc 的模板等等。这些功能会在业务使用过程中进行调整。后续，也会在服务端铺开，逐步的拓展业务面，为我们的业务开发交付降本增效。
参考文档：
https://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/doclet/overview.html
https://git-scm.com/docs/git-diff
版权声明: 本文为 InfoQ 作者【京东科技开发者】的原创文章。
原文链接:【http://xie.infoq.cn/article/9e4f90e0d787ea5b6199d9e9e】。文章转载请联系作者。
拥抱技术，与开发者携手创造未来！ 2018-11-20 加入
我们将持续为人工智能、大数据、云计算、物联网等相关领域的开发者，提供技术干货、行业技术内容、技术落地实践等文章内容。京东云开发者社区官方网站【https://developer.jdcloud.com/】，欢迎大家来玩
评论