Empirical Analysis of Build System Smells and Refactorings

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

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.