Empirical Analysis of Build System Smells and Refactorings

构建系统是一种基础设施，它通过以正确的顺序调用配置器、预处理器、编译器、测试工具、打包和部署工具，将软件系统的(文本)源代码转换为可执行程序。因为这种转换是基本的，所以大多数软件开发涉众每天都会与构建系统进行交互。例如，开发人员使用它来获取可执行文件，以对新功能或错误修复运行单元测试。构建系统还使持续集成服务器能够在开发人员签入软件变更时自动构建和测试。最后，最近持续交付的趋势是，Intuit、Mozilla和Google等公司在几天甚至几个小时内发布其软件的新版本，这需要一个强大、灵活和高性能的构建系统！然而，工业和开源领域的实际构建系统恰恰相反：70年代技术(如“make”)中的大型、单一的构建规范文件(如“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.