TY - GEN
T1 - Language Support for Refactorability Decay Prevention
AU - Fraivert, Dov
AU - Lorenz, David H.
N1 - Publisher Copyright: © 2022 ACM.
PY - 2022/12/1
Y1 - 2022/12/1
N2 - Even code that is free of smells may be at high risk of forming them. In such cases, developers can either perform preventive refactoring in order to reduce this risk, or leave the code as is and perform corrective refactoring as smells emerge. In practice, however, developers usually avoid preventive refactoring during the development phase, and when code smells eventually form, other developers who are less acquainted with the code avoid the more complex corrective refactoring. As a result, a refactoring opportunity is missed, and the quality and maintainability of the code is compromised. In this work, we treat refactoring not as a single atomic action, but rather as a sequence of subactions. We divide the responsibility for these subactions between the original developer of the code, who just prepares the code for refactoring, and a future developer, who may need to carry out the actual refactoring action. To manage this division of responsibility, we introduce a set of annotations along with an annotation processor that prevents software erosion from compromising the ability to perform the refactoring action.
AB - Even code that is free of smells may be at high risk of forming them. In such cases, developers can either perform preventive refactoring in order to reduce this risk, or leave the code as is and perform corrective refactoring as smells emerge. In practice, however, developers usually avoid preventive refactoring during the development phase, and when code smells eventually form, other developers who are less acquainted with the code avoid the more complex corrective refactoring. As a result, a refactoring opportunity is missed, and the quality and maintainability of the code is compromised. In this work, we treat refactoring not as a single atomic action, but rather as a sequence of subactions. We divide the responsibility for these subactions between the original developer of the code, who just prepares the code for refactoring, and a future developer, who may need to carry out the actual refactoring action. To manage this division of responsibility, we introduce a set of annotations along with an annotation processor that prevents software erosion from compromising the ability to perform the refactoring action.
KW - code reuse
KW - corrective refactoring
KW - extract function
KW - extract method
KW - move function
KW - move method
KW - preventive refactoring
KW - refactorability decay
KW - refactoring
UR - http://www.scopus.com/inward/record.url?scp=85211911926&partnerID=8YFLogxK
U2 - https://doi.org/10.1145/3564719.3568688
DO - https://doi.org/10.1145/3564719.3568688
M3 - منشور من مؤتمر
T3 - GPCE 2022 - Proceedings of the 21st ACM SIGPLAN International Conference on Generative Programming: Concepts and Experiences, Co-located with: SPLASH 2022
SP - 122
EP - 134
BT - GPCE 2022 - Proceedings of the 21st ACM SIGPLAN International Conference on Generative Programming
A2 - Scholz, Bernhard
A2 - Kameyama, Yukiyoshi
T2 - 21st ACM SIGPLAN International Conference on Generative Programming: Concepts and Experiences, GPCE 2022, co-located with ACM SIGPLAN Conference on Systems, Programming, Languages, and Applications, SPLASH 2022
Y2 - 6 December 2022 through 7 December 2022
ER -