Empirical Analysis of Build System Smells and Refactorings

点击翻译按钮获取中文摘要

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.