超越源代码的克隆：API文档和基础设施即代码实践研究

https://theses.hal.science/tel-02879899Mohamed Ameziane Oumaziz0HAL编号：tel-028798990于2020年6月24日提交0HAL是一个多学科开放获取档案，用于存储和传播科学研究文档，无论其是否已发表。这些文档可以来自法国或国外的教育和研究机构，或来自公共或私人研究中心。0HAL多学科开放档案，旨在存储和传播研究级科学文献，无论其是否已发表，来自法国或国外的教育和研究机构，公共或私人实验室。0超越源代码的克隆：API文档和基础设施即代码实践研究0引用此版本：0Mohamed Ameziane Oumaziz. 超越源代码的克隆：API文档和基础设施即代码实践研究. 软件工程 [cs.SE].波尔多大学, 2020. 英语. �NNT : 2020BORD0007�. �tel-02879899�Mohamed Ameziane OUMAZIZ0B ORDEAUX U  N I V E R S I T É  D  E  B  O R D E A UX S ciences et  T echnologies0博士论文0提交给波尔多大学波尔多计算机研究实验室以获得博士学位0专业：计算机科学 博士培养：计算机科学博士学院：数学与计算机科学0超越源代码的克隆：API文档和基础设施即代码实践研究0由0于2020年1月27日提交，评审委员会成员如下：0评审委员会主席Jean-Philippe D OMENGER ，教授。 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 波尔多大学，法国0导师Jean-Rémy F ALLERI ，讲师，HDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 波尔多国立理工学院，法国0导师Xavier B LANC ，教授。 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 波尔多大学，法国0报告员Mireille B LAY -F ORNARINO ，教授。 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 法国尼斯大学 TomM ENS ，教授。 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 比利时蒙斯大学0考官Anne E TIEN ，讲师，HDR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 法国里尔第一大学 Tew�k Z IADI，讲师，HDR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 索邦大学，法国LaBRI — 351, Cours de la Libération — 33400 Talence — France0摘要0在软件开发过程中，维护和演进占据了重要的部分，占据了总体成本和工作量的80%。在维护过程中，开发人员有时会复制和粘贴源代码片段以便重用。这种看似无害的做法比我们预期的更为频繁。这些源代码重复在文献中通常被称为“克隆”，是软件工程中一个众所周知且深入研究的主题。在本论文中，我们旨在揭示超越源代码的软件构件的复制粘贴实践。特别是，我们选择将贡献重点放在两种特定类型的软件构件上：API文档和部署文件（即Docker文件），因为它们分别：帮助开发人员理解如何使用和集成外部API，并代表开发人员和应用程序用户之间的最后一步。对于每种软件构件，我们采用了一种常见的经验研究方法。结果显示，API文档和软件部署文件（即Docker文件）中包含重复内容，并且这些重复内容在API文档中占27.69％到Docker文件中近50％的比例。然后，我们确定了存在这种重复内容的原因。此外，我们对经验丰富的开发人员进行了调查，发现他们知道这种重复内容，经常面对这种情况。但对于它们持有不同的意见。最后，我们发现这两种类型的软件构件都缺乏具有重用机制的工具来处理重复内容，一些开发人员甚至采用临时工具来管理它们。0关键词：文档、重复、Dockerfile、Docker、重用0摘要0在软件开发过程中，维护和演进是开发生命周期中重要的部分，占据了80%的成本和工作量。在维护过程中，开发人员有时会复制和粘贴源代码片段以便重用。这种看似无害的做法比人们想象的更为普遍。在文献中通常称为“克隆”的这些源代码重复是软件工程中一个众所周知且研究较多的主题。在本论文中，我们旨在揭示超越代码的软件构件上的复制粘贴实践。特别是，我们选择将重点放在两种类型的软件构件上：API文档和部署文件（即Dockerfile），因为它们分别：帮助开发人员理解如何使用和集成外部API，并代表开发人员和应用程序用户之间的最后一步。对于每个软件构件，我们采用了一种常见的经验研究方法。作为结果，我们展示了API文档和软件部署文件（即Dockerfile）存在重复，并且此类重复很常见，从27.69%（API文档）到近50%（Dockerfile）。随后，我们确定了这些重复存在的原因。此外，我们对经验丰富的开发人员进行了调查，发现他们意识到这些重复，并经常遇到它们，对此持有不同意见。最后，我们展示了这两种软件构件缺乏应对重复的重用机制，一些开发人员甚至使用临时工具来管理它们。0关键词：文档、重复、Dockerfile、Docker、重用i0目录01 引言 101.1 背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.2 问题陈述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.3 方法论  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501.4 贡献 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601.5 论文概述  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 背景 902.1 背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002.1.1 克隆定义  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002.1.2 克隆检测方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402.2 超越代码的软件构件中的克隆的实证研究  . . . . . . . . . . . . . . . . . . . . . . . 2102.3 克隆管理  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2802.4 摘要  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3003 API文档中的重复 3303.1 引言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3403.2 背景  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3503.3 数据收集  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3703.3.1 代码库  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3803.3.2 调查 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3903.3.3 重复项检测工具  . . . . . . . . . . . . . . . . . . . . . . . . 4003.4 贡献 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4103.4.1 RQ1：开发人员是否经常使用复制粘贴文档标签？ 4203.4.2 RQ2：文档标签复制粘贴的原因是什么？  . . . . 440ii 目录03.4.3 RQ3：适当使用文档工具是否可以避免重复文档？ . . . . . . . . . . . . . . . . . . . . . . . 5003.5 有效性威胁  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5203.6 结论  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5304 Dockerfile中的重复项 5504.1 引言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5604.2 背景  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5704.3 数据收集  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6004.3.1 仓库  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6004.3.2 调查 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6104.3.3 重复项检测工具  . . . . . . . . . . . . . . . . . . . . . . . . . 6204.4 贡献 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6404.4.1 RQ1：官方项目是否维护Dockerfile系列，为什么？ 6404.4.2 RQ2：Dockerfile系列中是否出现重复项，为什么？  . . . . . . 6604.4.3 RQ3：专家使用的工具的优缺点是什么，用于管理Dockerfile？  . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 7204.5 有效性威胁  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7704.6 结论  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7905 结论 8105.1 贡献总结  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8105.1.1 API文档中的重复项  . . . . . . . . . . . . . . . . . . . . 8105.1.2 Dockerfile中的重复项  . . . . . . . . . . . . . . . . . . . . . . . . 8205.2 展望和讨论  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8305.2.1 API文档中的重复项  . . . . . . . . . . . . . . . . . . . . 8305.2.2 Dockerfile中的重复项  . . . . . . . . . . . . . . . . . . . . . . . . 8405.2.3 讨论  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840A 法语摘要 870图表列表 1010表格列表 10311.4Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61.5Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .710章节0引言0通过本章，我们介绍了本论文的背景、动机和贡献。本论文旨在从实证角度研究两种类型的软件工件中的重复项。我们首先着重研究两种编程语言（Java和Ruby）的API文档中的重复项。然后我们解决了困扰Dockerfile的另一个重复项问题。在本章中，我们描述了这两个基本挑战和我们的主要贡献。0目录01.1 背景  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.2 问题陈述  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.3 方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52CHAPTER 1. INTRODUCTION1.1ContextWhen developing a software, maintenance and evolution represents an important partof the development’s life-cycle, making up to 80% of the overall cost and effort [Alkhatib,1992]. During the development or maintenance phase, it happens that developers resortto copying and pasting source code fragments. Commonly referred to as “clones” in theliterature, these source code duplicates are a well-known and deeply studied topic in soft-ware engineering. Multiple empirical studies [Baker, 1995; Baxter et al., 1998; Rieger et al.,2004; Zibran et al., 2011] have shown that large softwares can have from 5% up to 20% oftheir code base that is cloned.During the last two decades, many studies have tried to understand the underlyingreasons to resort to code clones [Baxter et al., 1998; Kapser, 2009; Rieger, 2005; Cordy, 2003].For instance, Cordi [Cordy, 2003] states that in the financial industry, cloning is a commonreuse strategy. He explains that since financial products aren’t that much different fromeach others, when a new product has to be developed, developers start by cloning a similarexisting project and then adapt it to produce the new product. Developers have to resort tosuch practices because monetary risks are very high in case of errors. Thus, any financialtool has to be heavily tested (70% of costs in financial softwares are spent on testing [Cordy,2003]). Therefore, it is cheaper and quicker to simply reuse existing source code by cloningit. Baxter et al. [Baxter et al., 1998] also writes about what is called accidental clones, thatare produced out of the awareness of the developer. Such clones may happen during theuse of libraries for instance, where developers have to write repetitive boilerplate code suchas a sequence of calls to perform a task.While some studies discuss the possible positive impact of code clones [Kapser andGodfrey, 2006], others state that code cloning isn’t inconsequential [Juergens et al., 2009b].Whether code clones are positive or not, during the maintenance process, if there is a bugin a cloned code fragment, developers have to propagate a bug-fix across all cloned frag-ments, this process might increase the maintenance costs. Moreover, developers might notall be aware that the bug exists somewhere else in his code base. Therefore, developers arerequired to know if their code is being cloned, and if so, where the other cloned fragmentsare located.During the last decade, multiple code clone detectors have been released. Clone de-tectors are used to identify similar or identical code snippets in a code base. Existing clonedetectors use a plethora of techniques such as AST-based (Abstract Syntax Trees) clone de-tection [Baxter et al., 1998], token-based code clone detection [Kamiya et al., 2002] or evendeep learning techniques [White et al., 2016a].While the software engineering community was very interested in code clones duringthe last two decades, there has been little interest in the existence of clones in softwareartifacts beyond source code. During a software system’s development process, severalby-products called software artifacts are also produced. These artifacts can be of differenttypes: API documentation, design diagrams, requirement specifications, build configura-1.2. PROBLEM STATEMENT3tion files, deployment files, etc. Non-code software artifacts can have a great impact onthe final product and thus, play a key role during the development process. Studies haveshown that it is also common to have clones in non-code software artifacts. For instance,multiple studies [Liu et al., 2006b; Störrle, 2013] have shown that UML diagrams are alsofacing duplicates exactly like source code. Juergens et al. [Juergens et al., 2010; Domannet al., 2009] show that requirement specifications can also face such duplicates. McIntoshet al. [McIntosh et al., 2014] show that build configuration files are also facing clone issues.Among all non-code software artifacts, we chose in this thesis to focus on studying theexistence of clones in: API documentation and deployment files (i.e. Dockerfiles). Wechose these two specific non-code software artifacts as they’re becoming widely availablein open-source projects. Further, the availability of these artifacts in open-source projectsmakes them a perfect fit for us to perform our empirical research studies. Finally, to thebest of our knowledge, no research study has studied clones on any of these two types ofartifacts in the past.In particular, we take a closer look at API documentations since it helps developersunderstand how to use and therefore integrate an external API they don’t know into theircode. We think that having clones on an API documentation could lead to inconsistenciesthat can mislead developers and maintainers, making them not correctly understand thebehavior of an API, thus extending the cost and effort of software development.Also, we chose to take a closer look at Dockerfiles which are a proprietary type of de-ployment files. Dockerfiles are used to package an application with all its dependenciesinto a single package that can then be easily released. These packages represent the laststep between developers and application users. Dockerfiles are written as a simple textfile composed of a sequence of instruction written a Domain Specific Language (DSL). Wethink that as Dockerfiles are similar to source code, if there is a bug in an a cloned in-struction, the developer has to propagate a bug-fix across all cloned instructions, makingit necessary for developers to be aware of the existence of clones on the first hand.Therefore, we believe that the community could benefit from these two empirical re-search studies given the importance of such artifacts.01.2 问题陈述0通过本论文，我们旨在研究软件工件中除了代码之外的复制粘贴维护负担。更具体地说，本工作的贡献是针对两种特定类型的工件：API文档和Dockerfile（一种部署文件类型）。在本节中，我们选择只展示从API文档中收集到的一个摘录。虽然我们可以随意选择我们研究的两种工件中的任何一种来展示，但我们选择只展示其中一种以便更容易理解我们的问题陈述。1/**5*/6public static booleanisEqualCollection(finalCollection a,final Collection b) {7...8return true;9}1/**6*/7public staticbooleanisEqualCollection(finalCollectiona, finalCollection b, final Equatorequator) {8...9returnisEqualCollection(collect(a, transformer),collect(b, transformer));10}04 第1章 引言0图1.1展示了一个真实的Java API文档摘录，来自于Java编写的Apache CommonsCollection项目。这两个方法都有一个使用特定领域语言JavaDoc编写的API文档。在这个摘录中，我们注意到两个API文档的很大一部分是重复的（以红色突出显示）。02 *  @param a 第一个集合，不能为空03 *  @param b 第二个集合，不能为空04 *  @return 当且仅当集合包含相同的元素和相同的基数时返回true。02 *  @param a 第一个集合，不能为空03 *  @param b 第二个集合，不能为空04 * @param equator 用于测试相等性的Equator05 *  @return 当且仅当集合包含相同的元素和相同的基数时返回true。0图1.1 - Apache CommonsCollection项目中由于方法委托而导致的文档重复的摘录。重复的文档以红色突出显示。0因此，我们想知道我们是否只是碰巧遇到了这种情况，这种情况是否罕见，或者实际上是频繁发生的，开发人员经常采用复制粘贴的方式。这个问题引导我们研究的第一个研究问题：0— RQ1: 开发人员经常采用复制粘贴吗？0然后，当仔细观察这个摘录时，我们注意到底部方法的返回值是通过调用上层方法（即委托）计算得出的。当进一步观察时，我们注意到这两个方法具有共同的输入参数和返回类型。1. https://github.com01.3. 方法论 50这是因为底部方法将其输入参数（a和b）传递给上层方法，并使用上层方法的返回值作为其返回值。由于这两个方法共享相同的输入参数（a和b），这导致它们也共享相应的文档，正如我们在图1.1中所看到的（以红色突出显示）。在这种情况下，API文档因为方法委托而被复制，我们想知道是否还有其他潜在原因会导致开发人员采用复制粘贴的方式。这引导我们研究的第二个研究问题：0— RQ2: 为什么开发人员会采用复制粘贴的方式？0最后，JavaDoc工具只提供了一个名为@InheritDoc的重用机制。这个重用机制允许开发人员在方法之间重用文档，但是这个机制仅适用于覆盖方法。由于在图1.1中我们只有一个委托场景，所以这个机制不适用。因此，我们想知道是否还有其他文档工具提供的其他重用机制，可以帮助开发人员避免这种复制粘贴。这构成了我们在本论文中研究的最后一个研究问题的推理：0— RQ3：通过适当使用最先进的方法，能够避免复制粘贴吗？0通过我们的三个研究问题，我们旨在使开发者和研究人员更加意识到非代码软件工件中存在重复项的存在。我们还旨在使研究界更加了解导致开发者采用复制粘贴的原因。最后，我们希望识别不同类型的重用机制，以帮助工具提供商更好地为其社区提供避免重复项的服务。因此，在本论文中，针对API文档和Docker�les软件工件，我们回答了以下三个研究问题：0— RQ1：开发者经常使用复制粘贴吗？0— RQ2：为什么开发者采用复制粘贴？0— RQ3：通过适当使用最先进的方法，能够避免复制粘贴吗？01.3 方法论0在本论文中，我们进行了两项实证研究。对于每项研究，我们依赖于两种知识来源：（1）一组Github1存储库，对应于我们研究中要分析的开源项目，以及（2）一组关于所研究工件中重复项的专家意见调查的响应。我们手动构建了这个调查，并将其发送给我们通过电子邮件或社交媒体联系的开发者专家。0第1章 引言0媒体（例如LinkedIn、Reddit、Github）。依靠这两种知识来源，我们采用三角验证方法来交叉验证我们的结果[ Seaman ,  1999 ;  Wood et al. ,  1999 ;  Miller ,  2008 ;  Bratthall and Jørgensen ,2002]。通过这种方法，我们旨在增加对收集结果的信心，因为它们由两个不同的知识来源进行验证。这种方法还减少了我们的整体偏见，因为我们的知识来源各自具有不重叠的偏见。为了回答我们的第一个研究问题：RQ1：开发者经常使用复制粘贴吗？，我们首先构建了一个自动解析数据集中所有github存储库的工具（依赖于Diggit工具2），并识别出存储库工件中的所有复制粘贴。然后，我们应用我们的工具并识别出所有重复项，这些重复项在一个Web应用程序中展示，以便于进行手动分析。然后，我们将这些结果与我们从调查中收集到的响应进行交叉验证。然后，为了回答我们的第二个研究问题：RQ2：为什么开发者采用复制粘贴？，我们从所有识别出的重复项中随机抽取一组样本，并要求三位专家使用我们为重复项分析开发的Web应用程序进行手动分析。为了进行这个分析，我们要求我们的专家寻找解释重复项实际存在的根本原因，并相应地标记每个重复项。我们不允许专家在标记过程中进行讨论。此外，如果两位专家对重复项的根本原因意见不一致，第三位专家必须决定哪个原因最有可能。最后，为了回答我们的最后一个研究问题：RQ3：通过适当使用最先进的方法，能够避免复制粘贴吗？，我们首先构建了一个列表，列出了我们正在研究的工件类型的所有可用工具。然后，我们手动查看列表中的每个工具，并阅读所有用户指南，寻找它们提供的所有重用机制。然后，对于我们在RQ2中确定的每个根本原因，我们查看是否有可以用来避免它的重用机制。然后，我们将这些结果与我们从调查中收集到的响应进行交叉验证。01.4 贡献0通过我们的工作，我们的目标是研究源代码以外的工件中的重复项。我们选择专注于两个主要工件：API文档和Docker�les。对于这两种工件，主要贡献可以总结如下：0- 我们表明API文档和软件构建文件实际上面临重复项问题，并且此类重复项很常见。0- 我们确定了存在此类重复项的原因