1 / 16

Why do we refactor? Technical Debt Items Versus Size: A Forensic Investigation of What Matters

Why do we refactor? Technical Debt Items Versus Size: A Forensic Investigation of What Matters. Ehsan Zabardast & Javier Gonzalez Huerta. Motivation:. The decisions behind refactoring the code: Preparing the system for future changes? Dealing with forms of technical debt?

bdugan
Download Presentation

Why do we refactor? Technical Debt Items Versus Size: A Forensic Investigation of What Matters

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Why do we refactor? Technical Debt Items Versus Size: A Forensic Investigation of What Matters Ehsan Zabardast & Javier Gonzalez Huerta

  2. Motivation: • The decisions behind refactoring the code: • Preparing the system for future changes? • Dealing with forms of technical debt? • Maintaining the code? • Code understandability? • … We started by investigating Technical Debt and File Size

  3. Study Design: Setup: empirical study 3 open source, java-based projects quantitative analysis on the repositories of selected projects commit level analysis

  4. Studied Cases:

  5. Research Question: Do refactorings happen on larger files or the files which contain Technical Debt Items?

  6. Methodology:

  7. Methodology:

  8. Results:

  9. Results:

  10. Results: • Number of TD Items does NOT Matter (p-value >.05 for all system) • Refactored or not-refactored, the files have similar number of TD Items • Refactoring does not happen just to remove the TD Items • The developers do not touch the files with more TD items • File Size Matters (p-value <.05 for all system) • To reduce the file size • Increasing maintainability • The more code you have the more problems appear

  11. Conclusions: • There are multiple reasons behind a decision for refactoring • We have investigated two of these • File size – Bigger files tend to get refactored • Technical Debt Items – The TD items in refactored files are not significantly different with non-refactored files

  12. What’s Comes Next: • Investigating the effectiveness of refactorings • Refactorings are effective for removing TD items • Identifying the TD reducing/inducing refactoring operations • TD items Survivability, i.e. how they die. • The impact of refactoring on maintainability • By investigating the relationship between change entropy and refactoring operations • Investigating the Developers’ Experience and Expertise on the project • Investigating asset management through developers’ perspective and experience, i.e., what matters.

  13. Systems’ Evolution:

  14. Refactoring Operations and TD Items:

  15. What’s Comes Next: • Investigating the effectiveness of refactorings • Refactorings are effective for removing TD items • Identifying the TD reducing/inducing refactoring operations • TD items Survivability, i.e. how they die. • The impact of refactoring on maintainability • By investigating the relationship between change entropy and refactoring operations • Investigating the Developers’ Experience and Expertise on the project • Investigating asset management through developers’ perspective and experience, i.e., what matters.

  16. Questions

More Related