Empirical Analysis of Build System Smells and Refactorings

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

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

构建系统是一个基础设施，它通过调用配置器、预处理器、编译器、测试工具、打包和部署工具，以正确的顺序将软件系统的（文本）源代码转换为可执行程序。因为这种转换是基本的，所以大多数软件开发涉众每天都与构建系统交互。例如，开发人员使用它来获取可执行文件，以便在新特性或bug修复上运行单元测试。构建系统还使持续集成服务器能够在开发人员检入软件更改时自动构建和测试。最后，最近持续交付的趋势是，像Intuit、Mozilla和谷歌这样的公司在几天甚至几个小时内发布他们软件的新版本，这需要一个强大、灵活和高性能的构建系统！