Abstract
In software development, ad hoc solutions that are intentionally implemented by developers are called self-admitted technical debt (SATD). Because the existence of SATD spreads poor implementations, it is necessary to remove it as soon as possible. Meanwhile, container virtualization has been attracting attention in recent years as a technology to support infrastructure such as servers. Currently, Docker is the de facto standard for container virtualization. In Docker, a file describing how to build a container (Dockerfile) is a set of procedural instructions; thus, it can be considered as a kind of source code. Moreover, because Docker is a relatively new technology, there are few developers who have accumulated good or bad practices for building Docker container. Hence, it is likely that Dockerfiles contain many SATDs, as is the case with general programming language source code analyzed in previous SATD studies. The goal of this paper is to categorize SATDs in Dockerfiles and to share knowledge with developers and researchers. To achieve this goal, we conducted a manual classification for SATDs in Dockerfile. We found that about 3.0% of the comments in Dockerfile are SATD. In addition, we have classified SATDs into five classes and eleven subclasses. Among them, there are some SATDs specific to Docker, such as SATDs for version fixing and for integrity check. The three most common classes of SATD were related to lowering maintainability, testing, and defects.
Highlights
Software developers often apply ad hoc solutions or workarounds to achieve their shortterm implementation goals (Alves et al 2014)
We analyzed self-admitted technical debt (SATD) in the comments of Dockerfiles to investigate the extent of SATD in the Docker platform
We found that SATD exists in Dockerfiles, as it does in other general programming languages
Summary
Software developers often apply ad hoc solutions or workarounds to achieve their shortterm implementation goals (Alves et al 2014). Such solutions are called technical debt as a metaphor of not-quite-right code which we postpone making it right (Cunningham 1992). Among these ad hoc solutions, one intentionally introduced by a developer and explicitly noted in source code comments is called self-admitted technical debt (SATD). Well-known SATDs are often commented with TODO or FIXME. Various SATD studies have been conducted on empirical study (Bavota and Russo 2016; Maldonado and Shihab 2015), automatic detection (Maldonado et al 2017b), repayment (Maldonado et al 2017a; Mensah et al 2018), and domain-specific (i.e., DNN framework) SATDs (Liu et al 2020)
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
