The Project

Problem: In large Java codebases, small design issues compound over time. Teams ship features, but technical debt quietly increases maintenance cost. My goal in this study was to treat refactoring as an engineering activity, not a cosmetic cleanup, then measure whether the changes made real maintenance tasks easier. What I did: I selected real-world Java systems (H2 Database, OpenPDF, and JFreeChart) and worked through concrete code smells and refactoring candidates surfaced by SonarQube and validated with RefactoringMiner. For each refactoring, I documented the original problem in plain terms, where it showed up in the code, and why it created friction during maintenance. Then I implemented the refactoring in a controlled way, keeping commits focused so it was easy to review and revert. How I worked: I used Git to isolate changes, ran tests before and after, and treated each refactoring like a small production change. When behaviour was unclear, I verified it by reading call paths, checking contracts, and using targeted tests to reduce guesswork. I also wrote short technical notes that explained the design decision behind each change so the next engineer would not have to rediscover the intent. Outcome: I compared the effort required to perform maintenance tasks before vs after the refactoring. The main value was improved readability and a cleaner separation of responsibilities, which reduced the mental load when tracing behaviour across classes. This project strengthened my ability to reason about existing systems, make safe changes, and communicate tradeoffs clearly.