一种基于抽象语法树的文件管理方法、装置及存储介质与流程

[0001]
本申请涉及计算机技术领域，尤其涉及一种基于抽象语法树的文件管理方法、一种基于抽象语法树的文件管理装置、一种计算机可读存储介质以及一种电子设备。


背景技术：

[0002]
基于线上的某些业务在不断满足用户需求时，要不断进行更新和迭代。整个业务系统的项目文件非常庞大，相互之间存在密切的引用和被引用的依赖关系，在业务系统的更新和迭代的过程中，就需要对业务系统内的项目文件进行管理，以免由于更新和迭代造成错误或混乱。比如，为了修改业务系统前端某个线上的功能，技术人员对系统内某个或某些项目文件进行了修改。如果不准确地找出在系统中受影响范围的文件并进行功能测试，将可能造成系统的错误或混乱。为此，技术人员通常会人工对系统内项目文件的关系进行清理，并判断是否受修改文件的影响。在庞大的业务系统中找出受修改文件的影响范围的工作量十分繁重，这不但浪费大量的人力资源，还严重影响业务系统在线上的效率和质量。


技术实现要素：

[0003]
针对上述现有技术，本申请实施例公开一种基于抽象语法树的文件管理方法，可以避免大量的人力进行管理，保证业务系统在线上的效率和质量。
[0004]
本申请实施例公开的一种基于抽象语法树的文件管理方法，具体为：
[0005]
一种基于抽象语法树的文件管理方法，该方法包括：
[0006]
利用抽象语法树分析出业务系统中项目文件之间的正向依赖关系，并为所述项目文件建立正向依赖记录以表示所述正向依赖关系；所述正向依赖关系表示从第一项目文件到第二项目文件的引用关系，所述第一项目文件引用所述第二项目文件，且所述第一项目文件的正向依赖记录的属性中包含第二项目文件的存储路径，所述业务系统中所述正向依赖记录属性中的存储路径构成全局路径对象集合；
[0007]
遍历所述全局路径对象集合中所述正向依赖记录的属性中的存储路径，为属性中的存储路径对应的第二项目文件创建反向依赖记录，所述反向依赖记录表示所述项目文件之间的反向依赖关系，且将引用所述第二项目文件的所有第一项目文件的存储路径添加到所述第二项目文件的反向依赖记录的属性中；
[0008]
在对项目文件进行修改时，利用被修改项目文件的反向依赖记录的属性逆向搜索项目文件，根据搜索到的项目文件确定受影响的项目文件范围，并将其同步给测试处理流程。
[0009]
进一步地，
[0010]
所述利用抽象语法树分析出业务系统中项目文件之间的正向依赖关系，并为所述项目文件建立正向依赖记录以表示所述正向依赖关系的步骤包括：
[0011]
将所述业务系统的一个入口文件作为当前入口文件；
[0012]
利用词法和语法分析方法为所述当前入口文件创建抽象语法树；
[0013]
遍历所述当前入口文件的抽象语法树，在遍历的过程中为所述当前入口文件的抽象语法树中的项目文件建立正向依赖记录，将所述项目文件自身作为第一项目文件，将其引用的项目文件作为第二项目文件，且将所述第二项目文件的存储路径添加到所述第一项目文件的正向依赖记录的属性中，并同时保存到创建的所述全局路径对象集合中；
[0014]
将所述业务系统的下一个入口文件作为当前入口文件，返回所述利用词法和语法分析方法为所述当前入口文件创建抽象语法树的步骤，直到处理完所述业务系统的入口文件。
[0015]
进一步地，
[0016]
所述为每一个项目文件建立正向依赖记录以表示所述正向依赖关系的步骤和所述遍历全局路径对象集合中所述正向依赖记录的属性的存储路径的步骤之间，该方法进一步包括：
[0017]
遍历所述系统业务中所有项目文件的正向依赖记录的属性，将所述正向依赖记录中重复的属性进行合并处理。
[0018]
进一步地，
[0019]
在对项目文件进行修改时，所述利用被修改项目文件的反向依赖记录的属性逆向搜索项目文件的步骤包括：
[0020]
将所述被修改项目文件作为当前第二项目文件；
[0021]
根据所述当前第二项目文件确定对应的反向依赖记录，获得其属性中保存的第一项目文件的存储路径，以确定反向搜索到的当前第一项目文件；
[0022]
将所述搜索到的当前第一项目文件作为第二项目文件，再返回执行所述根据当前第二项目文件确定对应的反向依赖记录的步骤，直到反向搜索到所述业务系统中的入口文件。
[0023]
进一步地，
[0024]
在将所述业务系统中的一个功能进行下线处理时，该方法进一步包括：
[0025]
确定需要下线的功能所对应的入口文件，将其作为待下线入口文件；
[0026]
从所述待下线入口文件开始，利用所述正依赖关系确定所述业务系统中所有需要被删除的项目文件，并在其所在的正向依赖记录的属性中进行标记；
[0027]
删除所述业务系统中需要被删除的项目文件，并遍历所述项目文件的正向依赖记录的属性，将属性中需要删除的标记所对应的引用关系进行删除。
[0028]
进一步地，
[0029]
所述从待下线入口文件开始，利用所述正依赖关系确定所述业务系统中需要被删除的项目文件，并在所述正向依赖记录的属性中进行标记的步骤包括：
[0030]
利用所述词法和语法分析方法为所述待下线入口文件创建抽象语法树；
[0031]
遍历所述待下线入口文件的抽象语法树，在遍历的过程中为所述待下线入口文件的抽象语法树中的项目文件建立正向依赖记录，将所述项目文件自身作为第一项目文件，将其引用的项目文件作为第二项目文件，将所述第二项目文件的存储路径添加到所述第一项目文件的正向依赖记录的属性中，并同时保存到创建的局部路径对象集合中，且计算所述第一项目文件的被引用次数；
[0032]
确定所述全局路径对象集合和所述局部路径对象集合中的相同存储路径对应的
项目文件；将所述相同项目文件中所述被引用次数相减，且将差值0作为所述需要删除的标记。
[0033]
本申请实施例还公开一种基于抽象语法树的文件管理装置，可以避免大量的人力进行管理，并保证业务系统在线上的效率和质量。本申请实施例公开的一种基于抽象语法树的文件管理装置，具体为：
[0034]
一种基于抽象语法树的文件管理装置，该装置包括：
[0035]
正向依赖记录建立单元，用于利用抽象语法树分析出业务系统中项目文件之间的正向依赖关系，并为所述项目文件建立正向依赖记录以表示所述正向依赖关系；所述正向依赖关系表示从第一项目文件到第二项目文件的引用关系，所述第一项目文件引用所述第二项目文件，且所述第一项目文件的正向依赖记录的属性中包含第二项目文件的存储路径，所述业务系统中正向依赖记录属性中的存储路径构成全局路径对象集合；
[0036]
反向依赖记录建立单元，用于遍历所述全局路径对象集合中所述正向依赖记录的属性中的存储路径，为属性中的存储路径对应的第二项目文件创建反向依赖记录，所述反向依赖记录表示所述项目文件之间的反向依赖关系，且将引用所述第二项目文件的所有第一项目文件的存储路径添加到所述第二项目文件的反向依赖记录的属性中；
[0037]
受影响范围确定单元，用于在对项目文件进行修改时，利用被修改项目文件的反向依赖记录的属性逆向搜索项目文件，根据搜索到的项目文件确定受影响的项目文件范围，并将其同步给测试处理流程。
[0038]
进一步地，
[0039]
所述正向依赖记录建立单元包括：
[0040]
第一抽象语法树建立子单元，用于将所述业务系统的一个入口文件作为当前入口文件，利用词法和语法分析方法为所述当前入口文件创建抽象语法树；
[0041]
第一建立记录执行子单元，用于遍历所述当前入口文件的抽象语法树，在遍历的过程中为所述当前入口文件的抽象语法树中的项目文件建立正向依赖记录，将所述项目文件自身作为第一项目文件，将其引用的项目文件作为第二项目文件，且将所述第二项目文件的存储路径添加到所述第一项目文件的正向依赖记录的属性中，并同时保存到创建的所述全局路径对象集合中；将所述业务系统的下一个入口文件作为当前入口文件，返回所述利用词法和语法分析方法为所述当前入口文件创建抽象语法树的步骤，直到处理完所述业务系统的入口文件。
[0042]
该装置进一步包括：
[0043]
合并单元，用于遍历所述系统业务中项目文件的正向依赖记录的属性，将所述正向依赖记录中重复的属性进行合并处理。
[0044]
进一步地，
[0045]
所述受影响范围确定单元包括：
[0046]
反向搜索子单元，用于将所述被修改项目文件作为当前第二项目文件，根据所述当前第二项目文件确定对应的反向依赖记录，获得其属性中保存的第一项目文件的存储路径，以确定反向搜索到的当前第一项目文件；
[0047]
指定子单元，用于将所述搜索到当前第一项目文件作为第二项目文件，再返回执行所述根据当前第二项目文件确定对应的反向依赖记录的步骤，直到反向搜索到所述业务
系统中的入口文件。
[0048]
该装置进一步包括：
[0049]
下线入口文件确定单元，用于在将所述业务系统中的一个功能进行下线处理时，确定需要下线的功能所对应的入口文件，将其作为待下线入口文件；
[0050]
删除对象确定单元，用于从所述待下线入口文件开始，利用所述正依赖关系确定所述业务系统中需要被删除的项目文件，并在其所在的正向依赖记录的属性中进行标记；
[0051]
删除执行单元，用于删除所述业务系统中需要被删除的项目文件，并遍历所述项目文件的正向依赖记录的属性，将属性中需要删除的标记所对应的引用关系进行删除。
[0052]
进一步地，
[0053]
所述删除对象确定单元包括：
[0054]
第二抽象语法树建立子单元，用于利用所述词法和语法分析方法为所述待下线入口文件创建抽象语法树；
[0055]
第二建立记录执行子单元，用于遍历所述待下线入口文件的抽象语法树，在遍历的过程中为所述待下线入口文件的抽象语法树中的项目文件建立正向依赖记录，将所述项目文件自身作为第一项目文件，将其引用的项目文件作为第二项目文件，将所述第二项目文件的存储路径添加到所述第一项目文件的正向依赖记录的属性中，并同时保存到创建的局部路径对象集合中，且计算所述第一项目文件的被引用次数；
[0056]
删除标记确定子单元，用于确定所述全局路径对象集合和所述局部路径对象集合中的相同存储路径对应的项目文件；将所述相同项目文件中所述被引用次数相减，且将差值0作为所述需要删除的标记。
[0057]
本申请实施例还公开一种计算机可读存储介质，其上存储有计算机指令，所述指令被处理器执行时可实现上述基于抽象语法树的文件管理方法。
[0058]
本申请实施例还公开一种电子设备，该电子设备至少包括如上所述的计算机可读存储介质，还包括处理器；
[0059]
所述处理器，用于从所述计算机可读存储介质中读取所述可执行指令，并执行所述指令以实现上述任一项所述基于抽象语法树的文件管理方法。
[0060]
综上，由于本申请实施例为业务系统中每一个项目文件建立了反向依赖记录，在某个项目文件进行修改时，根据反向依赖记录的追溯就可以获得业务系统的入口文件，快速地确定出受影响范围并同步给测试人员进行测试，避免由于修改项目文件带来的错误或混乱，节省大量的人力资源，保证整个业务在线上的效率和质量。
附图说明
[0061]
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
[0062]
图1表示本申请方法实施例一的流程图。
[0063]
图2表示业务系统中各项目文件之间依赖关系示意图。
[0064]
图3表示本申请方法实施例二的流程图。
[0065]
图4表示入口文件1下的项目文件之间依赖关系示意图。
[0066]
图5表示入口文件2下的项目文件之间依赖关系示意图。
[0067]
图6表示入口文件3下的项目文件之间依赖关系示意图。
[0068]
图7表示本申请方法实施例三的流程图。
[0069]
图8表示确定需要被删除的项目文件的方法流程图。
[0070]
图9表示删除下线功能后各项目文件之间依赖关系示意图。
[0071]
图10表示本申请装置实施例一的结构示意图。
[0072]
图11表示本申请装置实施例二的结构示意图。
[0073]
图12表示本申请装置实施例三的结构示意图。
[0074]
图13表示本申请电子设备的结构示意图。
具体实施方式
[0075]
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
[0076]
本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含。例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其他步骤或单元。
[0077]
下面以具体实施例对本发明的技术方案进行详细说明。下面几个具体实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。
[0078]
本申请实施例利用抽象语法树分析出业务系统的项目文件之间的正向依赖关系，由正向依赖关系表示从第一项目文件到第二项目文件的引用关系；利用正向依赖关系为每一个项目文件建立正向依赖记录；再遍历所有的正向依赖记录，创建反向依赖记录，以获得第二项目文件被第一项目文件引用的反向依赖关系，以便于业务系统修改时对受影响项目文件范围的确定和管理。
[0079]
图1是本申请实现基于抽象语法树的文件管理方法实施例一的流程图。如图1所示，该方法包括：
[0080]
步骤101：利用抽象语法树分析出业务系统中项目文件之间的正向依赖关系，并为每一个项目文件建立正向依赖记录以表示所述正向依赖关系；所述正向依赖关系表示从第一项目文件到第二项目文件的引用关系，所述第一项目文件引用所述第二项目文件，且将第二项目文件的存储路径添加到所述第一项目文件的正向依赖记录的属性中；所述业务系统中所有正向依赖记录属性中的存储路径构成全局路径对象集合。
[0081]
在计算机技术领域中，抽象语法树(ast，abstractsyntaxtree)是源代码语法结构的一种抽象表示，以树状形式表现变成语言的语法结构，其树上每个节点都表示源代码中
的一种结构。实际应用中，比如可以通过typescript语言提供的createsourcefile方法进行词法分析和语法分析而得到抽象语法树。
[0082]
由于业务系统中大量的项目文件之间存在依赖关系，利用人工对这种依赖关系进行分析的工作非常繁琐。本申请实施例不再采用人工分析，而是利用抽象语法树分析出业务系统中项目文件之间的正向依赖关系。比如：将业务系统的入口文件作为参数传递给typescript语言createsourcefile方法，经过createsourcefile方法的分析，就可以得到该入口文件的抽象语法树。如果业务系统有多个入口文件，则可以多次使用createsourcefile方法，得到业务系统所有入口文件的抽象语法树。
[0083]
本申请实施例所述的“依赖关系”是业务系统中一个项目文件和另一个项目文件之间的引用关系，并非特指某个特殊的项目文件。比如，其中一个项目文件称为“第一项目文件”，另一个项目文件称为“第二项目文件”。如果在第一项目文件中引用了第二项目文件，那么从第一项目文件到第二项目文件之间的依赖关系就称为正向依赖关系。为了清楚地表示这样的正向依赖关系，本申请实施例可以通过遍历抽象语法树，为每一个项目文件建立正向依赖记录，将引用的项目文件的存储路径添加到其记录的属性中。如果在第一项目文件中引用了第二项目文件，在遍历抽象语法树为第一项目文件建立正向依赖记录时，就可以将第二项目文件的存储路径添加到第一项目文件的属性中。
[0084]
图2表示某个业务系统中各项目文件之间依赖关系示意图。假设在某个业务系统有3个入口文件，这些入口文件引用了文件1～文件4，而文件1～文件4又分别引用子文件1～子文件6。此处仅为了表达项目文件之间的依赖关系，实际应用中，业务系统中的项目文件的数量更为庞大，且关系更为复杂。在此例中，当为入口文件2建立正向依赖记录时，由于入口文件2引用了文件2和文件4，因此入口文件2作为第一项目文件，文件2和文件4作为第二项目文件，且将文件2和文件4的存储路径添加到入口文件2的正向依赖记录的属性中。这里所述的第一项目文件和第二项目文件并不是某个特定的文件，而是指具有引用关系的两个文件。当建立文件2的正向依赖记录时，文件2将作为第一项目文件，其引用的子文件3和子文件5将作为第二项目文件。
[0085]
总之，按照上述方式可以为所有的项目文件建立正向依赖记录来表示正向依赖关系。那么，建立的所有正向依赖记录体现了业务系统中所有项目文件之间的正向依赖关系，其属性中的存储路径本申请实施例称为“全局路径对象集合”。“全局路径对象集合”并非其他特殊含义的集合，是指业务系统中所有正向依赖记录中存储路径的总和。
[0086]
步骤102：遍历所述全局路径对象集合中所有的正向依赖记录的属性中的存储路径，为每一个属性中的存储路径对应的第二项目文件创建反向依赖记录，所述反向依赖记录表示所述项目文件之间的反向依赖关系，且将引用所述第二项目文件的所有第一项目文件的存储路径添加到所述第二项目文件的反向依赖记录的属性中。
[0087]
如上所述，业务系统在业务各项功能不断修改和迭代过程中，某个项目文件会被修改。如果其他项目文件直接或间接引用了被修改的项目文件，则有可能会产生错误或混乱。因此，在某个项目文件会被修改时，需要确定直接或间接引用该被修改的项目文件的其他项目文件。但上述步骤101建立的是正向依赖记录，很难从中确定。为此，本步骤为项目文件建立了反向依赖记录。假设本申请实施例所述的“依赖关系”是业务系统中一个项目文件和另一个项目文件之间的引用关系。比如，其中一个项目文件称为“第一项目文件”，另一个
项目文件称为“第二项目文件”。如果在第一项目文件中引用了第二项目文件，那么从第一项目文件到第二项目文件之间的依赖关系就称为正向依赖关系，反之称为反向依赖关系。为了清楚地表示这样的反向依赖关系，本申请实施例遍历所有的正向依赖记录的属性，为每一个项目文件建立反向依赖记录，将引用自身的项目文件的存储路径添加到自身反向依赖记录的属性中。如果在第一项目文件中引用了第二项目文件，那么在遍历到第一项目文件的正向依赖记录时就可以确定第二项目文件，再为确定的第二项目文件建立反向依赖记录，并将第一项目文件的存储路径添加到第二项目文件的反向依赖记录的属性中。
[0088]
仍然以图2为例，假设遍历到文件2，文件2的正向依赖记录中包含子文件3和子文件5的存储路径。此时，可以为子文件3建立反向依赖记录，并将文件2的存储路径添加到子文件3的反向依赖记录的属性中，以此表示子文件3和文件2的反向依赖关系。
[0089]
步骤103：在对项目文件进行修改时，利用被修改项目文件的反向依赖记录的属性逆向搜索项目文件，根据搜索到的项目文件确定受影响的项目文件范围，并将其同步给测试处理流程。
[0090]
由于针对每一个项目文件建立了反向依赖记录，在某个项目文件进行修改时，查询被修改项目文件的反向依赖记录可以直接获得引用该被修改项目文件的其他项目文件，再逐层向上查询这些其他项目文件，最终会追溯到业务系统的某个或某些入口文件，从而快速地确定出受影响范围。此时，如果将确定的受影响范围的入口文件同步给测试人员，测试人员就可以仅对这些受影响的入口文件的某些功能进行测试，避免由于修改项目文件带来的错误或混乱，保证整个业务在线上的效率和质量。
[0091]
本申请还提供另一个基于抽象语法树的文件管理方法实施例二。在本实施例二中，正向依赖记录采用k-v类型的数据结构表示。图3是方法实施例二的流程图。如图3所示，该方法包括：
[0092]
步骤301：将业务系统的一个入口文件作为当前入口文件。
[0093]
步骤302：利用词法和语法分析方法为当前入口文件创建抽象语法树。
[0094]
步骤303：遍历当前入口文件的抽象语法树，在遍历的过程中为当前入口文件的抽象语法树中的每一个项目文件建立正向依赖记录，将所述每一个项目文件自身作为第一项目文件，将其引用的项目文件作为第二项目文件，且将第二项目文件的存储路径添加到所述第一项目文件的正向依赖记录的属性中，并同时保存到创建的全局路径对象集合中。
[0095]
上述步骤301～303为当前入口文件建立了抽象语法树和抽象语法树中所有项目文件的正向依赖记录。仍然以图2为例，当前入口文件为入口文件1时，建立的抽象语法树中项目文件之间引用关系的示意图为图4所示；当前入口文件为入口文件2时，建立的抽象语法树中项目文件之间引用关系的示意图为图5所示；当前入口文件为入口文件3时，建立的抽象语法树中项目文件之间引用关系的示意图为图6所示。
[0096]
其中，每一个项目文件的正向依赖记录可以采用k-v数据结构表示，其k值为正向依赖记录的记录名，v值可以作为正向依赖记录的属性。比如，在为入口文件1的抽象语法树中的文件1建立正向依赖记录时，该文件1的k-v数据结构可以表示为：
[0097][0098]
表一
[0099]
利用代码可表示如下：
[0100][0101]
其中，file1/index.js表示文件1的存储路径，作为文件1正向依赖记录的k值；sonfile1/index.js表示子文件1的存储路径，sonfile2/index.js表示子文件2的存储路径，sonfile4/index.js表示子文件4的存储路径，作为文件1正向依赖记录的v值。
[0102]
实际应用中，还可以为正向依赖记录设置其他属性，比如被引用次数，用以表示被遍历的当前项目文件被其他项目文件引用的次数。此时，其k-v数据结构可以表示为：
[0103][0104]
表二
[0105]
利用代码可表示如下：
[0106][0107][0108]
其中，value表示file1/index.js的被引用次数。当然，如果在文件管理过程中无需确定项目文件的被引用次数，也可以不设置“value”。
[0109]
在遍历抽象语法树时，可以先判断当前遍历的项目文件的存储路径是否已经保存在正向依赖记录的属性中，如果已经保存，则直接将其被引用次数(value值)加1；如果没有保存，则创建一个新的正向依赖记录(k-v数据结构)，将当前遍历的项目文件的存储路径作为其记录名(k值)，设置被引用次数(value)的初始值为1。
[0110]
步骤304：判断是否处理完所有的入口文件，如果是，则执行步骤306；否则，执行步骤305。
[0111]
步骤305：将下一个入口文件作为当前文件，并返回步骤302。
[0112]
按照上述步骤301～步骤305的方法，本申请实施例可以分别为各个入口文件下的项目文件建立正向依赖记录。由于某个入口文件下的项目文件为整个业务系统的一部分，且其正向依赖记录保存有项目文件的存储路径，在本申请实施例可以称为“局部路径对象集合”。
[0113]
步骤306：遍历系统业务中所有项目文件的正向依赖记录的属性，将所述正向依赖记录中重复的属性进行合并处理。
[0114]
虽然步骤301～步骤305已经为各个入口文件下的项目文件建立了正向依赖记录，但由于项目文件引用关系的复杂性，则可能会为某个项目文件建立重复的正向依赖记录。比如：在图4所示的入口文件1下的项目文件的依赖关系示意图中，文件1引用了子文件2，那么文件1的正向依赖记录的属性中将包含子文件2的存储路径，且会为子文件2建立正向依赖记录。而在图6所示的入口文件3的项目文件中，文件3也引用了子文件2，文件3的正向依赖记录的属性中也将包含子文件2的存储，且也会为子文件2建立正向依赖记录。为了避免为同一个项目文件建立重复的正向依赖记录而造成文件管理的混乱，本申请实施例利用步骤306将重复的属性进行了合并处理。当然，实际应用中，如果项目文件的正向依赖记录中的属性不重复，则无需进行合并处理，即省略本步骤306。在对重复属性进行合并处理时，可以将不同正向依赖记录的记录名(k值)合并，保证其属性(v值)的唯一性即可。
[0115]
此时，本申请实施例已经为业务系统中所有项目文件建立了正向依赖记录，这些正向依赖记录属性中的存储路径构成所述“全局路径对象集合”。
[0116]
步骤307：遍历全局路径对象集合中所有的正向依赖记录的属性中的存储路径，为每一个属性中的存储路径对应的第二项目文件创建反向依赖记录，所述反向依赖记录表示所述项目文件之间的反向依赖关系，且将引用所述第二项目文件的所有第一项目文件的存储路径添加到所述第二项目文件的反向依赖记录的属性中。
[0117]
本步骤与方法实施例一中的步骤102相同。建立的反向依赖记录也可以采用k-v数据结构可以表示，其k值为反向依赖记录的记录名，v值作为反向依赖记录的属性。仍然以图2为例，假设遍历到文件1的正向依赖记录中的属性(如子文件1的存储路径)，那么将会为子文件1建立反向依赖记录，子文件1的数据结构表示为：
[0118]
kv子文件1文件1
[0119]
表三
[0120]
｀sonfile1/index.js＇：{
[0121]
ꢀꢀꢀꢀꢀꢀꢀ
influencefactors[｀file1/index.js＇]
[0122]
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
}；
[0123]
其中，sonfile1/index.js表示子文件1的存储路径，作为子文件1反向依赖记录的k值，file1/index.js表示文件1的存储路径，作为子文件1反向依赖记录的v值。按照相同的方法，本步骤将建立业务系统所有的反向依赖记录。
[0124]
步骤308：在对项目文件进行修改时，将被修改项目文件作为当前第二项目文件。
[0125]
步骤309：根据当前第二项目文件确定对应的反向依赖记录，获得其属性中保存的第一项目文件的存储路径，以确定反向搜索到的当前第一项目文件。
[0126]
步骤310：判断是否搜索到入口文件，如果未搜索到入口文件，则执行步骤311；否
则，执行步骤312。
[0127]
步骤311：将所述搜索到的当前第一项目文件作为第二项目文件，返回步骤309。
[0128]
上述步骤308～步骤311是利用被修改项目文件的反向依赖记录的属性逆向搜索项目文件的具体实现方法。由于业务系统建立了反向依赖记录，因此可以利用反向依赖记录追溯。比如，子文件1进行了修改，根据子文件1的反向依赖记录(表三)可以查找到受影响的项目文件为文件1；相同地，再根据文件1的反向依赖记录可以查找到受影响的项目文件为入口文件1。当然，如果反向依赖记录的属性中有多个项目文件的存储路径，则需要针对其他项目文件进一步查找，同样也需要追溯到入口文件。
[0129]
步骤312：根据搜索到的项目文件确定受影响的项目文件范围，并将其同步给测试处理流程。
[0130]
与方法实施例一相同，本实施例在确定受影响范围时，也需要将受影响范围的入口文件同步给测试人员，测试人员就可以仅对这些受影响的入口文件的某些功能进行测试。假设确定受影响的入口文件为入口文件1，则需要将入口文件1同步给测试人员。这样，测试人员可以仅对入口文件1下的功能进行测试。进一步地，实际应用中，如果入口文件1下有若干功能，还可以仅将受影响的部分功能同步给测试人员，测试人员仅对入口文件1下的部分功能进行测试即可。由于本实施例利用建立的反向依赖记录追溯到受影响的项目文件范围，避免了由于修改项目文件带来的错误或混乱，保证整个业务在线上的效率和质量。另外，测试人员无需对整个业务系统进行测试，还可以大大提高测试效率。
[0131]
本申请上述实施例描述了一种基于抽象语法树的文件管理方法。在该文件管理方法下，当修改业务系统中的某个项目文件时，可以快速准确地确定受影响的项目文件范围。实际应用中，对业务系统还可能存在其他操作，将业务系统中的某个功能下线。在这种情况下，如果不清除该功能相关的项目文件，将会产生越来越多的冗余代码，不利于对业务系统的文件管理。针对这种情况，下面的方法实施例三为了清除需下线功能涉及的项目文件，同样利用了表示正向依赖关系的正向依赖记录，确定需下线功能涉及的项目文件的范围，然后将其进行删除。
[0132]
图7是本申请另一种基于抽象语法树的文件管理方法实施例三的流程图。在本申请方法实施例三中，假设已经利用步骤101的方法或者采用步骤301～306为业务系统中的所有项目文件建立了正向依赖记录，详细情况此处不再重复描述。当需要下线某个功能时，如图7所示，该方法包括：
[0133]
步骤701：确定需要下线的功能所对应的入口文件，将其作为待下线入口文件。
[0134]
业务系统的某个功能通常从某个入口文件开始实施，如果要下线某个功能，则需要先确定对应的入口文件，该入口文件直接或间接依赖的项目文件则是与即将下线的功能相关的项目文件。
[0135]
步骤702：从待下线入口文件开始，利用正依赖关系确定所述业务系统中所有需要被删除的项目文件，并在其所在的正向依赖记录的属性中进行标记。
[0136]
与上述方法实施例二为当前入口文件下的项目文件建立正向依赖记录的步骤相似，本申请实施例中的待下线入口文件下的项目文件也可以参照同样的方法建立正向依赖记录，那么待下线入口文件下所有的项目文件即需要被删除的项目文件。假设已经建立的“全局路径对象集合”为summarydeps集合，本步骤需要确定某个“局部路径对象集合”为
currentdeps集合，即待下线入口文件下直接或间接引用的项目文件。后续再将currentdeps集合中的存储路径从summarydeps集合中删除，并同时将存储路径对应的项目文件删除。
[0137]
步骤703：删除所述业务系统中所有需要被删除的项目文件，并遍历所有项目文件的正向依赖记录的属性，将属性中需要删除的标记所对应的引用关系进行删除。
[0138]
当确定了待下线入口文件对应的currentdeps集合，就可以通过比如delete方法可以将currentdeps集合中每一个存储路径对应的项目文件进行删除，同时将其从summarydeps集合中删除，即删除相关的引用关系。
[0139]
在本申请另一方法实施例中还进一步公开一种具体的确定需要被删除的项目文件的方法，即实现上述步骤702的具体方法。图8是确定需要被删除的项目文件的方法。如图8所示，该方法具体包括：
[0140]
步骤801：利用所述词法和语法分析方法为所述待下线入口文件创建抽象语法树。
[0141]
本步骤与上述方法实施例二中的步骤302相似，其区别在于，这里的入口文件是待下线的入口文件。
[0142]
步骤802：遍历所述待下线入口文件的抽象语法树，在遍历的过程中为所述待下线入口文件的抽象语法树中的每一个项目文件建立正向依赖记录，将所述每一个项目文件自身作为第一项目文件，将其引用的项目文件作为第二项目文件，将所述第二项目文件的存储路径添加到所述第一项目文件的正向依赖记录的属性中，并同时保存到创建的局部路径对象集合中，且计算所述第一项目文件的被引用次数。
[0143]
本步骤与上述方法实施例二中的步骤303相似，其区别在于，这里在创建正向依赖记录时，还需要设置第一项目文件的被引用次数，且在遍历过程计算第一项目文件的被引用次数。相似的，在遍历抽象语法树时，可以先判断当前遍历的项目文件的存储路径是否已经保存在正向依赖记录的属性中，如果已经保存，则直接将其被引用次数(value值)加1；如果没有保存，则创建一个新的正向依赖记录(k-v数据结构)，将当前遍历的项目文件的存储路径作为其记录名(k值)，设置被引用次数(value)的初始值为1。
[0144]
步骤803：确定所述全局路径对象集合和所述局部路径对象集合中的相同存储路径对应的项目文件。
[0145]
由于全局路径对象集合中包括了业务系统中所有项目文件的正向依赖记录中的存储路径，而这里的局部路径对象集合仅仅是其一部分，应该存在相同的存储路径。假设图2表示全局路径对象集合中所有存储路径，待下线入口文件为入口文件3，则图6表示局部路径对象集合中所有存储路径。那么，入口文件3、文件3、子文件2和子文件6就是其相同的存储路径对应的项目文件。
[0146]
步骤804：将所述相同项目文件中所述被引用次数相减，且将差值0作为所述需要删除的标记。
[0147]
由于需要将待下线入口文件对应的功能删除，那么待下线入口文件下的仅与待下线功能相关的项目文件才会被删除，而依然被其他功能依赖的项目文件则不允许删除。为了准确找出需要删除的项目文件，本方法实施例将引用次数差值为0的作为了需要删除的标记。假设全局路径对象集合中文件3的被引用次数为1，局部路径对象集合中文件3的被引用次数为1，相减差值为0，那么可以确定文件3是需要被删除的项目文件。
[0148]
按照本实施例方法，入口文件3对应的功能下线之后，删除下线功能的业务系统的各项目文件之间依赖关系示意图如图9所示。其中，入口文件3、文件3和子文件6被删除，而子文件2的被引用次数相减后为1，则不应该被删除。
[0149]
本申请上述方法实施例列举了不同操作对项目文件的管理方法，实际应用中还存在其他操作也可能对项目文件造成影响，同样可以利用本申请上述实施例方案对其进行管理。总之，应用本申请实施例方案，由于为业务系统的每一个项目文件建立正向依赖记录来体现各项目文件之间的依赖关系，可以利用该依赖关系很便捷地对业务系统中的项目文件进行管理，节约人力资源，显著提高业务系统在线上的效率和质量。
[0150]
针对上述基于抽象语法树的文件管理方法，本申请实施例还公开一种基于抽象语法树的文件管理装置。如图10所示，该装置实施例一的结构示意图包括：正向依赖记录建立单元a1、反向依赖记录建立单元a2、受影响范围确定单元a3。其中：
[0151]
正向依赖记录建立单元a1，用于利用抽象语法树分析出业务系统中项目文件之间的正向依赖关系，并为每一个项目文件建立正向依赖记录以表示所述正向依赖关系；所述正向依赖关系表示从第一项目文件到第二项目文件的引用关系，所述第一项目文件引用所述第二项目文件，且所述第一项目文件的正向依赖记录的属性中包含第二项目文件的存储路径，所述业务系统中所有正向依赖记录属性中的存储路径构成全局路径对象集合。
[0152]
反向依赖记录建立单元a2，用于遍历所述全局路径对象集合中所有的正向依赖记录的属性中的存储路径，为每一个属性中的中的存储路径的第二项目文件创建反向依赖记录，所述反向依赖记录表示所述项目文件之间的反向依赖关系，且将引用所述第二项目文件的所有第一项目文件的存储路径添加到所述第二项目文件的反向依赖记录的属性中。
[0153]
受影响范围确定单元a3，用于在对项目文件进行修改时，利用被修改项目文件的反向依赖记录的属性逆向搜索项目文件，根据搜索到的项目文件确定受影响的项目文件范围，并将其同步给测试处理流程。
[0154]
也就是说，正向依赖记录建立单元a1先利用抽象语法树分析出业务系统中项目文件之间的正向依赖关系，并为每一个项目文件建立正向依赖记录以表示所述正向依赖关系；再由反向依赖记录建立单元a2遍历全局路径对象集合中所有的正向依赖记录属性中的存储路径，为每一个属性中的存储路径对应的第二项目文件创建反向依赖记录；然后，在对项目文件进行修改时，受影响范围确定单元a3利用被修改项目文件的反向依赖记录的属性逆向搜索项目文件，根据搜索到的项目文件确定受影响的项目文件范围，并将其同步给测试处理流程。
[0155]
由于针对业务系统中每一个项目文件建立了反向依赖记录，因此在某个项目文件进行修改时，查询被修改项目文件的反向依赖记录可以直接获得引用该被修改项目文件的其他项目文件，再逐层追溯到入口文件，从而快速地确定出受影响范围。将确定的受影响范围的入口文件同步给测试人员，测试人员就可以仅对这些受影响的入口文件的某些功能进行测试，避免由于修改项目文件带来的错误或混乱，保证整个业务在线上的效率和质量。
[0156]
本申请还公开另外一种基于抽象语法树的文件管理装置实施例二。图11是该装置实施例二的结构示意图。如图11所示，该装置包括：正向依赖记录建立单元a1、反向依赖记录建立单元a2、受影响范围确定单元a3、合并单元a4。其中，正向依赖记录建立单元a1包括第一抽象语法树建立子单元a11、第一建立记录执行子单元a12。受影响范围确定单元a3包
括反向搜索子单元a31、指定子单元a32。具体的：
[0157]
第一抽象语法树建立子单元a11，用于将所述业务系统的一个入口文件作为当前入口文件，利用词法和语法分析方法为当前入口文件创建抽象语法树。
[0158]
第一建立记录执行子单元a12，用于遍历当前入口文件的抽象语法树，在遍历的过程中为当前入口文件的抽象语法树中的每一个项目文件建立正向依赖记录，将所述每一个项目文件自身作为第一项目文件，将其引用的项目文件作为第二项目文件，且将所述第二项目文件的存储路径添加到所述第一项目文件的正向依赖记录的属性中，并同时保存到创建的全局路径对象集合中；将业务系统的下一个入口文件作为当前入口文件，返回所述利用词法和语法分析方法为当前入口文件创建抽象语法树的步骤，直到处理完业务系统的所有入口文件。
[0159]
反向依赖记录建立单元a2，用于遍历所述全局路径对象集合中所有的正向依赖记录的属性中的存储路径，为每一个属性中的存储路径对应的第二项目文件创建反向依赖记录，所述反向依赖记录表示所述项目文件之间的反向依赖关系，且将引用所述第二项目文件的所有第一项目文件的存储路径添加到所述第二项目文件的反向依赖记录的属性中。
[0160]
反向搜索子单元a31，用于将所述被修改项目文件作为当前第二项目文件，根据所述当前第二项目文件确定对应的反向依赖记录，获得其属性中保存的第一项目文件的存储路径，以确定反向搜索到的当前第一项目文件。
[0161]
指定子单元a32，用于将所述搜索到的当前第一项目文件作为第二项目文件，再返回执行所述根据当前第二项目文件确定对应的反向依赖记录的步骤，直到反向搜索到业务系统中的入口文件。
[0162]
合并单元a4，用于遍历所述系统业务中所有项目文件的正向依赖记录的属性，将所述正向依赖记录中重复的属性进行合并处理。当然，实际应用中，如果如果项目文件的正向依赖记录中的属性不重复，则无需进行合并处理，即省略合并单元a4。在对重复属性进行合并处理时，可以将不同正向依赖记录的记录名(k值)合并，保证其属性(v值)的唯一性即可。
[0163]
应用本申请装置实施例方案，即，第一抽象语法树建立子单元a11将所述业务系统的一个入口文件作为当前入口文件，利用词法和语法分析方法为当前入口文件创建抽象语法树；第一建立记录执行子单元a12遍历当前入口文件的抽象语法树，为当前入口文件的抽象语法树中的每一个项目文件建立正向依赖记录，并按照此方法处理完所有的入口文件；合并单元a4遍历所有项目文件的正向依赖记录的属性，将正向依赖记录中重复的属性进行合并处理；反向依赖记录建立单元a2遍历所述全局路径对象集合中所有的正向依赖记录的属性中的存储路径，为每一个属性中的存储路径对应的第二项目文件创建反向依赖记录；反向搜索子单元a31将被修改项目文件作为当前第二项目文件，在反向依赖记录中反向搜索到的当前第一项目文件，并按照此方法直到反向搜索到业务系统中的入口文件，以确定受影响范围。
[0164]
本申请还公开另一种基于抽象语法树的文件管理装置实施例三。图12是本申请装置实施例三的结构示意图，如图12所示，该装置包括：正向依赖记录建立单元a1、反向依赖记录建立单元a2、受影响范围确定单元a3、合并单元a4(也可以不包括)，还包括下线入口文件确定单元a5、删除对象确定单元a6、删除执行单元a7。其中，正向依赖记录建立单元a1、反
向依赖记录建立单元a2、受影响范围确定单元a3、合并单元a4的功能与上述装置实施例二中的相同。删除对象确定单元a6包括第二抽象语法树建立子单元a61、第二建立记录执行子单元a62、删除标记确定子单元a63。具体的，
[0165]
下线入口文件确定单元a5，用于在将所述业务系统中的一个功能进行下线处理时，确定需要下线的功能所对应的入口文件，将其作为待下线入口文件。
[0166]
删除对象确定单元a6，用于从所述待下线入口文件开始，利用所述正依赖关系确定所述业务系统中所有需要被删除的项目文件，并在其所在的所述正向依赖记录的属性中进行标记。
[0167]
在删除对象确定单元a6中：
[0168]
第二抽象语法树建立子单元a61，用于利用所述词法和语法分析方法为所述待下线入口文件创建抽象语法树。
[0169]
第二建立记录执行子单元a62，用于遍历所述待下线入口文件的抽象语法树，在遍历的过程中为所述待下线入口文件的抽象语法树中的每一个项目文件建立正向依赖记录，将所述每一个项目文件自身作为第一项目文件，将其引用的项目文件作为第二项目文件，将所述第二项目文件的存储路径添加到所述第一项目文件的正向依赖记录的属性中，并同时保存到创建的局部路径对象集合中，且计算所述第一项目文件的被引用次数。
[0170]
删除标记确定子单元a63，用于确定所述全局路径对象集合和所述局部路径对象集合中的相同存储路径对应的项目文件；将所述相同项目文件中所述被引用次数相减，且将差值0作为所述需要删除的标记。
[0171]
删除执行单元a7，用于删除所述业务系统中所有需要被删除的项目文件，并遍历所有项目文件的正向依赖记录的属性，将属性中需要删除的标记所对应的引用关系进行删除。
[0172]
应用本申请实施例方案，即，在某个功能需要下线时，下线入口文件确定单元a5确定需要下线的功能所对应的入口文件，将其作为待下线入口文件；第二抽象语法树建立子单元a61利用所述词法和语法分析方法为所述待下线入口文件创建抽象语法树；第二建立记录执行子单元a62遍历所述待下线入口文件的抽象语法树，在遍历的过程中为所述待下线入口文件的抽象语法树中的每一个项目文件建立正向依赖记录，并将其引用的第二项目文件的存储路径保存到创建的局部路径对象集合中；删除标记确定子单元a63确定所述全局路径对象集合和所述局部路径对象集合中的相同存储路径对应的项目文件；将所述相同项目文件中所述被引用次数相减，且将差值0作为所述需要删除的标记；此后，删除执行单元a7删除所述业务系统中所有需要被删除的项目文件，并遍历所有项目文件的正向依赖记录的属性，将属性中需要删除的标记所对应的引用关系进行删除。
[0173]
本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储指令，所述指令在由处理器执行时可执行如上所述的基于抽象语法树的文件管理方法的步骤。实际应用中，所述的计算机可读介质可以是上述实施例各设备/装置/系统所包含的，也可以是单独存在，而未装配入该设备/装置/系统中。其中，在计算机可读存储介质中存储指令，其存储的指令在由处理器执行时可执行如上所述基于抽象语法树的文件管理方法中的步骤。
[0174]
根据本申请公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存
储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件，或者上述的任意合适的组合，但不用于限制本申请保护的范围。在本申请公开的实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
[0175]
如图13所示，本发明实施例还提供一种电子设备。如图13所示，其示出了本发明实施例所涉及的电子设备的结构示意图，具体来讲：
[0176]
该电子设备可以包括一个或一个以上处理核心的处理器1301、一个或一个以上计算机可读存储介质的存储器1302以及存储在存储器上并可在处理器上运行的计算机程序。在执行所述存储器1302的程序时，可以实现上述基于抽象语法树的文件管理方法。
[0177]
具体的，实际应用中，该电子设备还可以包括电源1303、输入输出单元1304等部件。本领域技术人员可以理解，图13中示出的电子设备的结构并不构成对该电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：
[0178]
处理器1301是该电子设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器1302内的软件程序和/或模块，以及调用存储在存储器1302内的数据，执行服务器的各种功能和处理数据，从而对该电子设备进行整体监控。
[0179]
存储器1302可用于存储软件程序以及模块，即上述计算机可读存储介质。处理器1301通过运行存储在存储器1302的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器1302可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据服务器的使用所创建的数据等。此外，存储器1302可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器1302还可以包括存储器控制器，以提供处理器1301对存储器1302的访问。
[0180]
该电子设备还包括给各个部件供电的电源1303，可以通过电源管理系统与处理器1301逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源1303还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。
[0181]
该电子设备还可包括输入输出单元1304，该输入单元输出1304可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。该输入单元输出1304还可以用于显示由用户输入的信息或提供给用户的信息以及各种图像用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。
[0182]
本申请附图中的流程图和框图，示出了按照本申请公开的各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或者代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应该注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同附图中所标准的顺序发生。例如，两个连接地表示的方框实际上可以基本并行地执行，它们有时也可以按照相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或者流程图中的方框的
组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
[0183]
本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本申请中。特别地，在不脱离本申请精神和教导的情况下，本申请的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，所有这些组合和/或结合均落入本申请公开的范围。
[0184]
本文中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思路，并不用于限制本申请。对于本领域的技术人员来说，可以依据本发明的思路、精神和原则，在具体实施方式及应用范围上进行改变，其所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。