代码影响范围工具探索

作者：京东零售 田创新、耿蕾

一、背景

1.祖传代码不敢随意改动，影响范围无法评估。并且组内时常有因为修改了某块代码，导致其他业务受到影响，产生bug，影响生产。

2.研发提测完成后，测试进入测试后经常会向研发询问本次需求改动影响范围，以此来确定测试用例，以达到精准测试，提升整个需求的质量，缩短交付周期。

那么，如何才能规避这种隐患？有没有一种工具能够协助代码研发及review人员更加精确的判断当前代码改动影响范围，有没有一种方法能够提供除了业务逻辑条件验证，针对代码作用范围，给测试人员提供精确验证链路？

二、方案调研

技术方案调研

经过各方资料查找及比对，最终我们整理了两个满足我们需求的方案：

1.IDEA提供了显示调用指定Java方法向上的完整调用链的功能，可以通过“Navigate -> Call Hierarchy”菜单(快捷键：control+option+H)使用，缺点是并没有向下的调用链生成。

2.开源框架调研：wala/soot静态代码分析工具。

针对上述的调研，大致确认了两种方案，集中分析两种方案的优劣，来制定符合我们目前情况的方案：

工具名称	优势	劣势	是否符合
Call Hierarchy	支持方法向上调用链	功能比较单一，数据无操作性	否
wala/soot静态代码分析	能够完善的分析Java中任何逻辑包括方法调用链，且满足我们目前的需求	臃肿，复杂繁琐，功能过于庞大	否

经过前期的比较以及相关工具的资料调研、工具功能分析，并考虑到后期一些个性化功能定制开发，以上工具不太满足我们目前的需求，所以决定自己动手，丰衣足食，尝试重新开发一个能够满足我们需求的工具，来协助研发以及测试人员。

三、方案制定

预期：工具尽量满足全自动化，研发只需要接入即可，减少研发参与，提升整个调用链展示和测试的效率。并且调用链路应该在研发打包的过程中触发，然后将数据上传至服务端，生成调用链路图。

上述方案制定完成后，需要进一步确认实现步骤。前期我们确认了工具的大概的方向，并进行步骤分解，根据具体的功能将整个工具拆分成六个步骤

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 行，则识别为一个新的文件，并用正则表达式提取文件名 ：

String[] lines = out.toString().split("\\r?\\n");
Pattern pattern = Pattern.compile("^diff --git a/\\S+ b/(\\S+)");

b.用正则表达式提取 @@ -149 +148,0 @@ ，用来解析代码修改行数:

Pattern pattern = Pattern.compile("^@@ -[0-9]+(,[0-9]+)? \\+([0-9]+)(,[0-9]+)? @@");

c.针对我们的需求，我们只关心本次修改影响的是那个方法，不关心具体影响了哪些行数，所以我们只需要

int changeLineStart = Integer.parseInt(m.group(2));

就拿到了本次修改，修改开始的代码行数, 在结合ASM就可以获取到本次改动影响的具体方法。

2.利用获取的行号定位具体的方法。

​ 根据上述1步骤中定位出研发每次提交的修改的Java源文件和改动的行号位置，我们需要定位修改代码行号所归属的方法名称，再由方法名称+类名+包名去定位本次修改的影响链路。

如何去定位？

首先确定的是，研发在工程中只能修改的是工程中的源文件，所以我们可以在遍历收集整个工程的源文件的过程中根据已知的修改行号来确定修改的方法名称，进而知道整个方法的调用链路。而对对于那些没有落到方法体范围之内的行号，基本上可以确认为类变量或常量，考虑到对于常量修改也可能影响到业务逻辑，所以我们也会对修改的Field进行上下调用的范围的查找，所以需要记录。所以整个过程分成两个部分：

​ a.遍历源码Class文件，获取整个类的Field；

​ b.遍历Class文件的过程中，通过visitMethod遍历整个方法体，记录方法的初始行号和结束行号，来定位方法；

首先是a部分，确认Field，ClassVisitor提供现成的方法：

    @Override
    public FieldVisitor visitField(int access, String name, String desc, String signature, Object value) {
        Log.i("jingdong","Field name is :%s desc is %s: ",name,desc);
        return super.visitField(access, name, desc, signature, value);
    }

所以我们可以在文件中直接获得整个类的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方法中需要进行区分处理，代码如下：

project.afterEvaluate {
            def android = project.extensions.android
            def config = project.method
  				if (config.enable) {
  					//应用级别
            if (project.plugins.hasPlugin('com.android.application')) {
                android.applicationVariants.all { variant ->
                    MethodTransform.inject(project, variant)
                }
            }else{
              	//aar编译处理--
                //这里我们是在compileReleaseJavaWithJavac之后运行自定义Task
                Task javaWithJavacTask = project.tasks.findByName("compileReleaseJavaWithJavac")
                if (javaWithJavacTask != null) {
                     def customTask = project.tasks.create("JDcustomTask", JdParseClassTask.class)
                     javaWithJavacTask.finalizedBy(customTask)
                    }else {
                        new GradleException("创建task失败~~")
                    }
            		}
						}
        }

两者的处理逻辑一致，也就是在Task的监听有些区别，所以下面我们不重复复述，以MethodTransform为主线进行讲解。

那有的同学就问了，为啥我们不直接对源文件.java文件进行处理呢？

因为，就目前京东主站项目而言，各个aar模块相互调用，如果我们仅仅使用源文件进行扫描，各个aar或者jar包的调用链会断掉不全面，影响代码review人员及测试人员的测试用例完整度。

接下来是代码实现，我们监听任务执行，并针对需要监听的任务开展我们的Class收集操作：

 //Project
project.getGradle().getTaskGraph().addTaskExecutionGraphListener(new TaskExecutionGraphListener() {
     @Override
     public void graphPopulated(TaskExecutionGraph taskGraph) {
         for (Task task : taskGraph.getAllTasks()) {
           //对满足我们需求的Task执行前，
           if(task.name.equalsIgnoreCase("transformClassesWithDexForDebug")){
             //执行我们的TrasnsformTask
             //省略。。。。
      }}}})

2.2 排除非class文件的干扰，对源文件路径进行递归遍历；

代码的编译长短对研发的影响很大，所以编译时长很宝贵，需要我们尽量的减少编译的时长，所以我们在执行我们自定义的Transform过程中，需要过滤并排除非Class文件，减少不必要的浪费。经过整理主要为：R文件以及R文件的内部类R$\ast 文件，包括R$string、R$styleable等等，所以，在遍历处理过程中我们需要对R文件及R$*文件过滤。

public static final String[] UN_VISITOR_CLASS = {"R.class", "R$"};

2.3 提供ClassVisitor类和MethodClass去搜集Class及对应Method，并定位

这个步骤是最主要的一部分，这一部分主要获取两部分数据，第一部分是研发修改直接影响到的类和方法；第二部分是遍历整个源文件的所获得的类信息，主要包括类+各个方法以及各个方法体，也就是方法中的指令；

在拿到transformInvocation后我们进行源文件文件夹遍历和所有jar包的遍历，在外层我们定义好存储被影响的类列表（changedClassesList），和包含类信息的列表（classesInfoList），将两个列表作为参数，传递进去在遍历过程中赋值。这里值得注意的是，在进行jar解析过程中不需要进行changedClassesList，因为对于本工程来说研发人员不会直接对jar文件中文件操作。

//修改类列表
List<LinkedClassInfo> changedClassesList = new ArrayList<>()
//类信息列表
List<Map<String, List<Map<String, List<MethodInsInfo>>>>> classesInfoList = new ArrayList<Map<String, List<Map<String, List<MethodInsInfo>>>>>()
transformInvocation.inputs.each { TransformInput input ->
      //所有源文件生成的class
      input.directoryInputs.each { DirectoryInput dirInput ->
           collectDir(dirInput, isIncremental, classesInfoList, changedClassesList)
       }
       //所有jar包集合
       input.jarInputs.each { JarInput jarInput ->
           if (jarInput.getStatus() != Status.REMOVED) {
                //可以取到jar包集合
                collectJar(jarInput, isIncremental, classesInfoList,jarOutputFile)
                }
         }
   }

在对源文件遍历过程中，我们进行定位搜寻。

遍历源文件根节点并读取：

if (file != null) {
            //根布局目录进行循环遍历
            File[] files = file.listFiles()
            files.each { File f ->
                if (f.isDirectory()) {
                    collectJar(f, classList,changedClasss,changedLineInfoMap)
                } else {
                    boolean isNeed = true
                    //对文件类型进行校验，排除一些无意义的配置性文件
                    //省略。。。
                    if (isNeed) {
                        try {
                          //类集合（包含：类名+方法名+方法指令）
                            Map<String, List<Map<String, List<MethodInsInfo>>>> mClassMethodsList = new HashMap<String, List<Map<String, List<MethodInsInfo>>>>()
                            ClassReader cr = new ClassReader(new FileInputStream(f))
                            ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_FRAMES)
                          //重写ClassVisitorAdapter
                            ClassVisitorAdapter ca = new ClassVisitorAdapter(cw, mClassMethodsList,changedClasss ,changedLineInfoMap )
                            cr.accept(ca, ClassReader.EXPAND_FRAMES)
                            classList.add(mClassMethodsList) //将类的整个方法和指令加进去
                        } catch (RuntimeException re) {
                            re.printStackTrace()
                        } catch (IOException e) {
                            e.printStackTrace()
                        }
                    }
                }
            }
        }

重写ClassVisitor，ASM提供的visit方法可以很方便的去识别这个类的各种信息，而我们用到的信息为两种，一种是接口类型的判定，一种是当前类的类名。对于接口，我们没有必要去进行Method的访问，对获得的类名信息我们进行判定当前类是否是git最后提交有做过修改的的类：

@Override
    public void visit(int version, int access, String name, String signature, String superName, String[] interfaces) {
        cv.visit(version, access, name, signature, superName, interfaces);
        owner = name;//类名
      	//判定不为接口类型
        isInterface = (access & Opcodes.ACC_INTERFACE) != 0;
        //这里判断是否修改是否包含此类
        if (this.mChangedLineInfoMap!=null&&mChangedLineInfoMap.size()>0){
            for (Map.Entry<String,ChangedLineInfo> changedLineInfoEntry:this.mChangedLineInfoMap.entrySet()){
                String filePath = changedLineInfoEntry.getKey();
                if(filePath.contains(owner)){
                    //包含此类
                    linkedClassInfo= new LinkedClassInfo();
                    linkedClassInfo.className = owner;
                    mChangedLineInfo= changedLineInfoEntry.getValue();
                    methodNameList = new ArrayList<>();
                    linkedClassInfo.methodNameList = methodNameList;
                }
            }
        }
    }

`在上述的visit中我们定位了当前类是否与上次git提交的是否有关，接下来我们需要MethodVisitor中进行有选择的拦截对应的Method的访问。

重写MethodVisitor在visitMethod中进行拦截处理，如果git修改相关在当前类中，则我们在访问Method时，进行方法体行数定位。

mv = new MethodVisterAdapter(mv,
                    owner,
                    access,
                    //省略。。。
                    mChangedLineInfo //更改行数位置
                    );

在MethodVisitor中，我们可以通过系统方法定位访问方法的每条方法指令及指令对应的行数，所以我们只要重写visitLineNumber方法即可实时的在visitMethodInsn方法中拿到方法体访问行数，这里有个小的注意点就是，我们在调用visitLineNumber返回的line不是我们理解意义上的方法名称部分开始，而是从方法体的第一行代码计算开始，所以我们在做判断的时候，需要注意，相对方法体的首行，我们更关心方法体的变更，所以我们只需要判定落在visitMethodInsn中的更改即可。有需要更加精细的判定，小伙伴可以进行更加精细的调研。

以下是visitLineNumber方法：

    @Override
    public void visitLineNumber(int line, Label start) {
        this.lineNumber = line;//置换lineNumber
        super.visitLineNumber(line, start);
    }

知道了方法体开始的地方，我们也需要知道结束的位置，获取到结束位置后，我们就能轻松的定位到我们需要的定位的方法体，从而获得方法名称，进一步获得类的名称。ASM在MethodVisitor中提供了visitEnd方法，表示方法体访问结束，那么我们就可以在visitEnd中进行定位：

@Override
public void visitEnd() {
    super.visitEnd();
    int startLine = this.startLineNumber;
    int endLine = this.lineNumber;
    boolean isContained = false;
    if (this.mChangedLineInfo!=null&&mChangedLineInfo.lineNumbers!=null&&mChangedLineInfo.lineNumbers.size()>0){
        for (String line : this.mChangedLineInfo.lineNumbers){
            if (line!=null){
               int lineNum = Integer.parseInt(line);
              //是否落在xx方法中
               if (lineNum>=startLine&&lineNum<=endLine){
                   isContained = true;
                    break;
                 }
              }
          }
      }
      if (isContained&&this.methodNameList!=null){
         //包含在此方法中
         MethodName nameContained = new MethodName();
         nameContained.methodName = name;
         this.methodNameList.add(nameContained);
        }
  			//保存
        methodInsMapList.put(name, mMethodInsInfoList);
    }

至此，我们通过自定义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以及一些三方库，我们大致总结了一下几种，供大家参考：

public static final String[] SYSTEM_PACKAGES = {"java/*", "javax/*", "android/*", "androidx/*","retrofit2/*","com/airbnb/*","org/apache/*"};

示意图如下：

至此，我们完成了方法上/下行链路的搜索。

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-docletcommand-line option, it will default to the standard doclet to produce HTML-format API documentation.

也就说，我们需要在命令行中添加 -doclet来进行自定义文档。并且给出自定义的Doclet类：

	public static  class JDDoclet {
		public static boolean start(RootDoc root) {
			JDJavaDocReader.root = root;
			return true;
		}
	}

接下来简单的封装tools中的execute方法：

public synchronized static RootDoc readDocs(String source, String classpath,String sourcepath) {
		if (!Strings.isNullOrEmpty(source)){ //java源文件或者为包名
			List<String> args = Lists.newArrayList("-doclet",
					JDDoclet.class.getName(), "-quiet","-encoding","utf-8","-private");
			if(!Strings.isNullOrEmpty(classpath)){
				args.add("-classpath");//source的class位置，可以为null，如果不提供无法获取完整注释信息（比如无法识别androidx.annotation.NonNull）
				args.add(classpath);
			}
			if(!Strings.isNullOrEmpty(sourcepath)){
				args.add("-sourcepath");
				args.add(sourcepath);
			}
			args.add(source);
			int returnCode = com.sun.tools.javadoc.Main.execute(JDJavaDocReader.class.getClassLoader(),args.toArray(new String[args.size()]));
			if(0 != returnCode){
				Log.i(TAG,"javadoc ERROR CODE = %d\n", returnCode);
			}
		}
		return root;
	}

其中命令中参数，感兴趣的小伙伴可以查看官方文档，这里就不再赘述了。

基本封装完成后，就可以直接使用了，但是考虑到在遍历使用的过程中会出现多次调用解析ClassDoc的问题，这里还是建议将解析过的Java文件进行缓存处理，方便直接调用，也能减少整个编译的时间，并且在解析过程中我们也需要排除系统类的解析。

//....略
if(classDoc!=null){
     javaDocFile.append("\n\n")
      //获取类注释并写入文件
     javaDocFile.append(classDoc.getClassComment())
     javaDocFile.append(className+"\n")
     doc = classDoc.getClassDoc()
 }
//....略
if (doc!=null){
    for (MethodDoc methodDoc : doc.methods()) {
         //添加自定义Tag
         methodDoc.tags(MethodBuildConstants.CUSTOM_TAG)
         if (method.methodName.trim() == methodDoc.name().trim()){
             Tag[] tags = methodDoc.tags()
             if (tags!=null&&tags.length>0){
             		//取自定义Tag内容
                 for (int i = 0;i<tags.length;i++){
                      if (tags[i].name() == "@"+MethodBuildConstants.CUSTOM_TAG){
                          javaDocFile.append(tags[i].text()+"\n")
                          javaDocFile.append(method.methodName+"\n")
                        }
              }
           }else{//如果没有tag则输出对应的所有注释
                javaDocFile.append(methodDoc.commentText()+"\n")
                javaDocFile.append(method.methodName+"\n")
            }
         }
      }
  }

这里我们也给出自定义Tag，当然，在项目中可以根据自己的业务名称进行命名。

/**
 * 自定义tag标签
 */
public static final String CUSTOM_TAG = "LogicIntroduce";

完成了功能的开发，我们需要在代码中中进行验证，测试如下：

/**
 * 打印方法（谁调用就会被打印），会打印两次
 * @LogicIntroduce 这个是自定义Tag  getPrintMethod方法
 */
public static void getPrintMethod(){
    System.out.println("我被调用了");
    getPrintMethod2();
}

当我们的方法调用链涉及到getPrintMethod()时，就会提取@LogicIntroduce标签后面的内容，达到了获取业务逻辑说明注释的目的。这样对于那些不动代码的非研发人员，也能够非常清晰的看懂这部分代码涉及到的业务逻辑，测试也能够着重的进行测试了。

本地输出：

影响类：com/jd/fragment/test/utils/TestUtils.java （测试类）
影响方法：
  getPrintMethod（这个是自定义Tag  getPrintMethod方法）

5.推荐实际业务使用

方法的调用上下链路在上述步骤中已经生成，我们可以在MarkDown中简单的生成调用链，至于要遵循什么样的格式，大家可以自己查阅，相对比较简单不再展开。下面是推荐位最近一次修改涉及到的部分流程图：

代码修改位置输出为：

com/jingdong/xxx/RecommendItem.java //被修改的文件
252	 //修改的行

向上调用链展示：

向下调用链，我们只取本方法体：

相关Javadoc输出：

//上行调用链
影响类：com/jingdong/xxx/RecommendItem（推荐位基础数据bean对象）
影响方法：
  productExpoData（生成曝光数据给外部使用）
  generateExpoData（商卡构造曝光用数据）
  setData（服务端JSON数据解析）

影响类：com/jingdong/xxx/RecommendProductPageView （推荐UI组件）
影响方法：
	toRecomendList（网络接口返回数据）

影响类：com/jingdong/xxx/RecommendProductPageView$3（服务端数据处理（内部类））
影响方法：
	toList（接口数据处理）

//下行调用链
影响类：com/jingdong/xxx/RecommendItem（推荐位基础数据bean对象）
影响方法：
  productExpoData（生成曝光数据给外部使用）
      -com/jd/xxx/JDJSONObject

五、总结

经过上面的描述，我们整体上完成了再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