Successfully reported this slideshow.

Refactoring Debt: Myth or Reality? An Exploratory Study on the Relationship Between Technical Debt and Refactoring

0

Share

Loading in …3
×
1 of 11
1 of 11

Refactoring Debt: Myth or Reality? An Exploratory Study on the Relationship Between Technical Debt and Refactoring

0

Share

Download to read offline

In-Person presentation at: The 19th International Conference on Mining Software Repositories (MSR '22)

Date of Conference: 24 May 2022
Conference Location: Pittsburgh, PA, USA

Preprint: https://www.peruma.me/publication/2022-msr-debt/2022-MSR-DEBT.pdf

In-Person presentation at: The 19th International Conference on Mining Software Repositories (MSR '22)

Date of Conference: 24 May 2022
Conference Location: Pittsburgh, PA, USA

Preprint: https://www.peruma.me/publication/2022-msr-debt/2022-MSR-DEBT.pdf

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Refactoring Debt: Myth or Reality? An Exploratory Study on the Relationship Between Technical Debt and Refactoring

  1. 1. Refactoring Debt: Myth or Reality? An Exploratory Study on the Relationship Between Technical Debt and Refactoring Anthony Peruma, Eman A. AlOmar, Christian D. Newman, Mohamed W. Mkaouer & Ali Ouni The 19th International Conference on Mining Software Repositories Mining Challenge Track
  2. 2. Intentionally documenting improvements to the source code Self-Admitted Technical Debt Non-optimal code shipped to production Technical Debt
  3. 3. GOAL IMPACT RESEARCH QUESTIONS CONTRIBUTION Explore the repayment of technical debt through refactoring operations Provide developers and tool vendors with insight to improve code quality Extent of the removal of technical debt through refactoring Types of debt addressed through refactoring Dataset and discussion of the impact of refactoring and debt repayment
  4. 4. Source Dataset SmartSHARK MongoDB Release 2.1 (full version) Extracted Data ▪ SATD Removed Commits ▪ Refactoring Commits ▪ Refactoring Operations ▪ Hunks (Code Diffs) Quantitative Analysis ▪ Descriptive Statistics ▪ Odds Ratio Qualitative Analysis ▪ Manual Analysis of Code Custom Python Scripts Experiment Design Data Overview ▪ # of projects: 77 ▪ # of project with SATD removed: 76 ▪ # of commits with SATD removed: 13,259 ▪ # of refactoring commits with SATD removed: 7,341
  5. 5. Research Questions RQ1 – To what extent do developers refactor code when removing technical debt? Greater likelihood of debt repayment through refactoring activities: • 76 of 77 systems have debt removal via refactoring • 76 systems have an Odds Ratio > 1 • Statistically significant difference in the number of refactoring operations applied to files Developers apply a variety of refactoring operations: • Extract Attribute is frequently applied multiple times followed by Change Variable Type
  6. 6. Research Questions RQ2 – What motivates a developer to refactor their source code to remove technical debt? Technical debt categories resolved via refactoring: ▪ Error Handling ▪ Code & Structural Improvements ▪ Feature Updates
  7. 7. Code & Structural Improvements Clean-up Activities Design Improvements Includes removing temporary code or renaming identifiers Prior studies show that code clean-up is an activity associated with refactoring Includes moving code (such as moving methods, method extraction, etc.) and data type changes Frequent bigrams & (stemmed) terms: “get rid”, “mov”, “remov” & “chang” Rename attribute refactoring operation Change data type refactoring operation
  8. 8. Feature Updates Refactoring operations developers perform to incorporate feature changes into the system Frequent terms: ▪ “implement” – “FIXME: our implementation is flawed….” ▪ “add” – “TODO: Add method to extract...” Extract method refactoring operation
  9. 9. Error Handling Developers knowingly write code prone to errors or utilize generic (or auto- generated) error handling code (try/catch blocks) Common bigrams: “catch block”, “error handling”, “exception handling”, and “throw exception” ▪ “TODO: We could use a better strategy for error handling” ▪ “TODO: Fix exception handling”.
  10. 10. Potential Code Quality Tools: • Support for robust error handling – automatic detection of shortcomings in the code; customization of auto-generated try- catch blocks • Improving the accuracy of refactoring recommendations – considering the occurrence of SATD in the code • Aligns with existing studies showing a co-occurrence between debt repayment and refactoring actions • Opens the door for potential future work A more formal and exhaustive set of causes for repayment categories Conclusion & Takeaways
  11. 11. Thank You! Anthony Peruma h t t p s ://pe ru ma. me

×