Empirical Analysis of Build System Smells and Refactorings

构建系统气味和重构的实证分析

• 批准号: RGPIN-2014-04838
• 负责人: Adams, Bram
• 金额: $ 2.33万
• 依托单位: École Polytechnique de Montréal
• 依托单位国家: 加拿大
• 项目类别: Discovery Grants Program - Individual
• 财政年份: 2014
• 资助国家: 加拿大
• 起止时间: 2014-01-01 至 2015-12-31
• 项目状态: 已结题
• 来源: https://www.nserc-crsng.gc.ca/ase-oro/Details-Detailles_eng.asp?id=566773
• 关键词: Empirical; Analysis; Build; System; Smells

A build system is the infrastructure that transforms the (textual) source code of a software system into an executable program by invoking configurators, preprocessors, compilers, test harnesses, packaging and deployment tools in the correct order. Because this transformation is fundamental, most software development stakeholders interact with the build system on a daily basis. For example, developers use it to obtain an executable to run unit tests on a new feature or bug fix. The build system also enables continuous integration servers to automatically build and test whenever a developer checks in a software change. Finally, the recent trend of continuous delivery, where companies like Intuit, Mozilla and Google release new versions of their software in a couple of days or even hours, requires a powerful, flexible and highly performant build system! However, real-life build systems in industry and open source are quite the opposite: large, monolithic build specification files in '70s era technology (like "make"), hardly understood by any developer, fully at the mercy of one talented project member. Even though the source code evolves constantly, adapting the build system to these changing requirements is hard and often results in patched-up versions of the existing build architecture. The latter problem is due to the rigid build system architecture, the developers' unfamiliarity with (often arcane) build technology like "make", and the low priority of build system changes for unsuspecting project managers. Hence, the build system becomes more complex and less performant, with team members getting frustrated and tampering with code dependencies to speed up builds. Such tampering in turn introduces other side-effects like inconsistent build errors or unpredictable build performance. The main goal of my research program is to derive a set of patterns and best practices for build system maintenance that will enable any software development stakeholder to maintain their build system (e.g., "make" or "ant" files) in a systematic, disciplined, quantifiable way. In particular, this program aims to compile catalogues of bad smells (indicators of a potential quality issue) and refactorings of the build system (and related entities), and to build developer support to recommend applicable refactorings and perform refactorings selected by the stakeholder. The catalogues will be based on interviews with open source developers and build system engineers, as well as large-scale empirical analyses of thousands of open source systems using three generations of build system technologies. We will also perform user studies with open source and industry participants to validate our IDE support. Given the central role of the build system in software development, our research results will be directly applicable by the Canadian industry, providing competitive advantage to both large software companies, like IBM and RIM, and smaller SMEs. In particular, companies will be able to enhance their dashboards with crucial, but currently missing indicators of the health of their build system. The identified patterns and best practices will provide a succinct vocabulary and methodology for all build system stakeholders to discuss and treat build system problems effectively. Above all, our results will allow practitioners to systematically integrate their build system into a successful continuous delivery process. The research plan will train 4 High Quality Personnel (HQP), i.e., 2 PhD and 2 Master students, who will gain extensive hands-on experience with empirical research techniques and industry-grade build systems. This training qualifies them for the demanding and much sought after roles of build and release engineers for large-scale software systems.

构建系统是通过以正确的顺序调用配置器、预处理器、编译器、测试装备、打包和部署工具将软件系统的（文本）源代码转换为可执行程序的基础设施。因为这种转换是基本的，所以大多数软件开发涉众每天都与构建系统进行交互。例如，开发人员使用它来获取可执行文件，以对新功能或错误修复运行单元测试。构建系统还使持续集成服务器能够在开发人员签入软件更改时自动进行构建和测试。最后，最近的持续交付趋势，像Intuit，Mozilla和Google这样的公司在几天甚至几小时内发布新版本的软件，需要一个强大，灵活和高性能的构建系统！然而，工业和开源中的真实构建系统恰恰相反：70年代技术中的大型、单一的构建规范文件（如“make”），几乎没有开发人员理解，完全取决于一个有才华的项目成员。即使源代码不断发展，使构建系统适应这些不断变化的需求也是困难的，并且通常会导致现有构建体系结构的修补版本。后一个问题是由于刚性的构建系统架构，开发人员不熟悉（通常是《双城之战》）像“make”这样的构建技术，以及不知情的项目经理对构建系统更改的低优先级。因此，构建系统变得更加复杂，性能降低，团队成员感到沮丧，并篡改代码依赖项以加快构建速度。这种篡改反过来又会带来其他副作用，如不一致的构建错误或不可预测的构建性能。我的研究计划的主要目标是导出一组用于构建系统维护的模式和最佳实践，这些模式和最佳实践将使任何软件开发涉众都能够维护他们的构建系统（例如，“make”或“ant”文件）。特别是，该计划旨在编译构建系统（和相关实体）的不良气味（潜在质量问题的指标）和重构的目录，并建立开发人员支持，以推荐适用的重构并执行由涉众选择的重构。目录将基于对开源开发人员和构建系统工程师的采访，以及对使用三代构建系统技术的数千个开源系统的大规模实证分析。我们还将与开源和行业参与者进行用户研究，以验证我们的IDE支持。鉴于构建系统在软件开发中的核心作用，我们的研究成果将直接适用于加拿大行业，为IBM和RIM等大型软件公司和小型中小企业提供竞争优势。特别是，公司将能够通过关键但目前缺少的构建系统健康指标来增强其仪表板。识别的模式和最佳实践将为所有构建系统涉众提供一个简洁的词汇表和方法，以有效地讨论和处理构建系统问题。最重要的是，我们的结果将允许从业者系统地将他们的构建系统集成到成功的持续交付过程中。研究计划将培养4名高素质人员（HQP），即：2名博士生和2名硕士生，他们将获得经验研究技术和行业级构建系统的广泛实践经验。这种培训使他们有资格担任大规模软件系统的构建和发布工程师的要求苛刻和备受追捧的角色。