State of Refactoring Adoption: Better Understanding Developer Perception of Refactoring

TL;DR

This paper investigates how developers document refactoring activities, proposes a model to identify such documentation, and provides insights into review challenges and best practices for refactoring documentation.

Contribution

It introduces a SAR taxonomy and model for documenting refactoring, aiding in early detection of inconsistencies and improving understanding of developer intent.

Findings

Developers face challenges in communicating refactoring intent.

A proposed procedure improves refactoring documentation practices.

Survey reveals reviewer difficulties in understanding refactoring implications.

Abstract

We aim to explore how developers document their refactoring activities during the software life cycle. We call such activity Self-Affirmed Refactoring (SAR), which indicates developers' documentation of their refactoring activities. SAR is crucial in understanding various aspects of refactoring, including the motivation, procedure, and consequences of the performed code change. After that, we propose an approach to identify whether a commit describes developer-related refactoring events to classify them according to the refactoring common quality improvement categories. To complement this goal, we aim to reveal insights into how reviewers decide to accept or reject a submitted refactoring request and what makes such a review challenging.Our SAR taxonomy and model can work with refactoring detectors to report any early inconsistency between refactoring types and their documentation. They can serve as a solid background for various empirical investigations. Our survey with code reviewers has revealed several difficulties related to understanding the refactoring intent and implications on the functional and non-functional aspects of the software. In light of our findings from the industrial case study, we recommended a procedure to properly document refactoring activities, as part of our survey feedback.