MORCoRA: Multi-Objective Refactoring Recommendation Considering Review Availability

This paper proposes MORCoRA, a multi-objective search-based technique that recommends code quality-improving refactoring sequences along with suitable reviewers by simultaneously optimizing for expertise and workload availability to ensure the refactorings can be promptly reviewed.

The Gist

Imagine you are the captain of a busy ship (a software project). You realize the ship needs some repairs and upgrades to sail smoother and faster. You have a brilliant engineer (an AI tool) who can tell you exactly which planks to replace and how to rearrange the cargo to make the ship better.

However, there's a catch: You can't just fix the ship while it's sailing. You need to get permission from your crew, and more importantly, you need to find crew members who actually know how to fix that specific part of the ship and aren't currently drowning in other work.

This is the problem the paper MORCoRA solves.

Here is the breakdown in simple terms:

1. The Problem: The "Perfect Plan" That Never Happens

In the world of software, developers often use "Search-Based Refactoring." Think of this as a GPS that plots the perfect route to fix code. It looks for ways to make the code cleaner, faster, and less buggy.

But in the real world, a perfect plan is useless if:

• The Reviewer is clueless: You ask a chef to review a mechanic's engine repair. They don't know enough to say "yes" or "no."
• The Reviewer is too busy: You ask the only mechanic on the ship to review the repair, but they are already fixing the engine, painting the deck, and cooking dinner. They will ignore your request or delay it forever.

The paper argues that most AI tools only look for the "perfect repair" but ignore whether anyone is actually available to approve it. This leads to great ideas that sit in a drawer, never getting applied, while the ship's quality slowly rots.

2. The Solution: MORCoRA (The Smart Captain's Assistant)

The authors created a new tool called MORCoRA. Instead of just looking for the best repair, it looks for the best repair that can actually get approved.

It balances three goals, like a chef trying to make a meal that is:

1. Delicious (Code Quality): The code must actually get better.
2. Safe to Eat (Semantic Coherence): The fix must make sense. You can't move a "brake pedal" to the "steering wheel" just because it looks neat; the car won't work.
3. Ready to Serve (Review Availability): This is the new, special ingredient. The tool checks:
   • Who knows this code? (Expertise)
   • Who has free time right now? (Workload)

If the tool finds a great fix but the only expert is swamped with 10 other tasks, MORCoRA says, "Nope, let's skip this one and find a different fix that a busy-but-capable person can handle."

3. How It Works (The Recipe)

The tool uses a "genetic algorithm." Imagine a garden where you are trying to grow the perfect plant.

• You start with 100 random ideas for fixes.
• You test them against your three goals (Taste, Safety, Availability).
• You keep the best ones, mix their "DNA" (combine parts of different fixes), and mutate them (make small random changes).
• Over time, the garden fills with plants that are delicious, safe, and ready to be picked by a gardener who isn't too busy.

4. The Results: Does It Work?

The researchers tested this on six popular software projects (like the ones you might use on your phone or computer).

• The "Old Way" (Ignoring Availability): Found great fixes, but often suggested them to people who were too busy or didn't know the code. The "approval rate" was low.
• The "MORCoRA Way": Found fixes that were slightly less "perfect" in a theoretical sense, but were 433% more likely to actually get approved because they matched the right person with the right free time.

The Analogy:

• Old Tool: "Here is the best recipe for a cake! Give it to the head chef!" (But the head chef is asleep and the sous-chef doesn't know how to bake). Result: No cake.
• MORCoRA: "Here is a very good recipe. Give it to the sous-chef who is currently on a break and knows how to bake." Result: A cake gets made.

5. The Big Takeaway

The paper concludes that we need to stop treating software development like a math problem where only the "best answer" matters. We have to treat it like a team sport.

If you want to improve your software, you can't just find the best fix; you have to find the best fix that your team can actually handle right now. MORCoRA is the tool that helps you do exactly that, ensuring that good ideas don't get stuck in "review purgatory."

Technical Summary

Here is a detailed technical summary of the paper "MORCoRA: Multi-Objective Refactoring Recommendation Considering Review Availability."

1. Problem Statement

Search-based software engineering (SBSE) techniques are widely used to automatically identify sequences of refactorings to improve code quality. However, a critical gap exists in current approaches: they often recommend refactorings that are technically sound but practically unimplementable due to human resource constraints.

• The Review Bottleneck: Before applying refactorings, they must be reviewed by developers. If the recommended sequence lacks "review availability," it may be postponed or rejected.
• Review Availability Criteria: A refactoring sequence has high review availability only if it can be reviewed by a small group of developers who meet two criteria:
  1. Expertise: They possess sufficient knowledge of the specific code files being modified.
  2. Workload: They are not currently overwhelmed by other tasks (e.g., active Pull Requests or Issues).
• The Consequence: Ignoring these factors leads to "shelf-ware" refactorings—suggestions that improve theoretical quality metrics but are never applied, causing software quality to stagnate or decay.

2. Methodology: MORCoRA

The authors propose MORCoRA (Multi-Objective Refactoring Recommendation Considering Review Availability), a search-based technique built on the NSGA-II (Non-dominated Sorting Genetic Algorithm II) evolutionary algorithm.

Core Objectives

MORCoRA optimizes for three simultaneous objectives:

1. Code Quality Improvement: Maximizing the improvement in maintainability metrics (Reusability, Flexibility, Understandability, Functionality, Extendibility, Effectiveness) using the QMOOD model.
2. Semantic Coherence: Ensuring that refactored elements (e.g., moving a method) remain semantically related to their new location. This is measured by combining Vocabulary-based Similarity (VS) and Dependency-based Similarity (DS).
3. Review Availability (RA): Maximizing the likelihood that the refactoring can be reviewed. This is a novel metric calculated as:
   • Expertise ($Exp$): Calculated based on a developer's commit frequency and recency (weighted by how recently they contributed to a file).
   • Workload ($WL$): Calculated based on the number of active Pull Requests and Issues a developer is involved in during a specific time window.
   • RA Score: A sequence is valid only if it can be assigned to a group (max 2 reviewers) where $WL \leq Threshold$ and $Exp > 0$.

Technical Workflow

1. Static Analysis: Uses JxPlatform2 to extract abstract representations (class structures) and call graphs from the source code.
2. Data Extraction: Analyzes Git commit history for expertise and GitHub Pull Request/Issue history for workload.
3. Search Process:
   • Solution Representation: A vector of refactoring operations (e.g., Move Method, Inline Class).
   • Evolutionary Operators: Uses Crossover (SBX) and Mutation to evolve populations of refactoring sequences.
   • Selection: NSGA-II ranks solutions based on non-dominated sorting and crowding distance to find the Pareto front (the set of optimal trade-offs between the three objectives).
4. Output: A set of Pareto-optimal refactoring sequences along with the specific reviewers best suited to approve them.

3. Key Contributions

• MORCoRA Framework: The first search-based refactoring tool that explicitly integrates review availability as a primary optimization objective alongside code quality and semantic preservation.
• Review Availability Metric: A novel quantitative metric that combines developer expertise (frequency + recency) and current workload (active PRs/Issues) to predict the feasibility of a review.
• Comprehensive Evaluation:
  • Evaluated on six large-scale open-source Java repositories (e.g., Mockito, Retrofit, Glide).
  • Compared against five different search algorithms (NSGA-II, SPEA2, IBEA, MOCell, Random Search).
  • Benchmarked against the state-of-the-art technique by Ouni et al. (which lacks the review availability objective).
• Human-in-the-Loop Validation: A qualitative analysis where an expert manually assessed 60 random solutions to verify they eliminated code smells, preserved semantics, and were reviewable.

4. Results

The evaluation yielded significant quantitative and qualitative findings:

• Effectiveness (RQ1):
  • MORCoRA successfully found solutions that improved code quality, preserved semantics, and had high review availability.
  • 58.3% of the manually assessed solutions were confirmed to be meaningful, reviewable, and capable of eliminating code smells.
• Algorithm Performance (RQ2):
  • NSGA-II demonstrated the best overall performance across the three objectives compared to SPEA2, MOCell, IBEA, and Random Search.
  • IBEA performed poorly, often failing to find diverse solutions.
• Comparison with Existing Techniques (RQ3):
  • When compared to the baseline technique (Ouni et al.) that ignores review availability:
    • MORCoRA increased the ratio of reviewable solutions by an average of 433.8%.
    • While MORCoRA's solutions had slightly lower Quality (Qual) and Semantic (Sem) scores (approx. 25% and 33% lower, respectively), the Review Availability (RA) score was 533.8% higher.
  • Qualitative Insight: The baseline technique frequently recommended refactorings that required reviewers who were either too busy or lacked expertise, rendering those suggestions impractical. MORCoRA avoided these "unreviewable" traps.

5. Significance and Conclusion

• Practical Impact: The study highlights that a "perfect" refactoring is useless if no one is available to review it. By optimizing for review availability, tools can bridge the gap between theoretical code improvement and actual deployment.
• Resource Awareness: It introduces a paradigm shift in SBSE, moving from purely technical metrics to socio-technical metrics that account for developer capacity and expertise.
• Future Directions: The authors suggest extending workload tracking across multiple projects (not just the target repo) and incorporating non-programming workloads to further refine the availability metric.

In summary, MORCoRA proves that considering the human element (reviewer availability) in automated refactoring tools significantly increases the likelihood that recommended improvements will be accepted and applied in real-world software development.