5 exercises on proposing refactors and justifying technical debt paydown. Choose the most natural and professional option.
0 / 10 completed
1 / 10
You want to explain why a codebase needs major cleanup. Which phrasing is most professional?
KEY PHRASE: "This code has accumulated a lot of debt — I'd like to propose a cleanup sprint" "Technical debt" is the neutral, professional metaphor that engineers recognise — debt accumulates through reasonable short-term decisions, not negligence. It doesn't blame individuals. "Cleanup sprint" proposes a concrete delivery format. Real examples: "This module has accumulated significant debt over 3 years — I'd like to address it in Q3"; "The auth layer has accumulated a lot of debt — proposing a 2-week cleanup sprint." Options B and C are reactive and alarmist ("really messy", "bad shape"), escalating anxiety without a plan. Option D explicitly blames people, which damages team relationships and credibility.
2 / 10
You want to convince the team to refactor before adding new features. What's the best argument?
KEY PHRASE: "I'd like to refactor this before adding more features — the current structure will make the new work harder" This is persuasive and practical. It proposes ("I'd like to"), explains the reason (current structure), and directly links the refactor to the upcoming feature work. It's proactive rather than obstructive. Real examples: "I'd like to refactor the data layer before we add the new filters — the current coupling will slow us down"; "Refactoring first makes sense here — the structure isn't designed for what we're about to build." Options A and B sound like blockers without offering a rationale or path forward. Option D is negative and doesn't propose a solution.
3 / 10
You want to explain the consequences of deferring the refactor. Which phrasing is most persuasive?
KEY PHRASE: "The risk of NOT refactoring is that every new feature will take twice as long and introduce more bugs" This is rhetorically strong because it reframes the cost of inaction rather than making a positive case for the work. Naming specific consequences ("twice as long", "more bugs") makes the argument concrete and measurable. Real examples: "The risk of not refactoring is compounding complexity — every sprint gets slower"; "The risk of NOT addressing this now is that the next team to touch it will spend a week just understanding it." Options A, C, and D are vague assertions with no specificity. They sound like warnings without evidence, which engineers (rightly) discount.
4 / 10
You're proposing a gradual approach to avoid a big-bang refactor. Which is clearest?
KEY PHRASE: "We could do it incrementally — starting with X, then working up to Y" "Incrementally" is the key word — it signals a disciplined, low-risk approach that engineering managers and senior engineers recognise and trust. Naming the sequence (data layer first, then API boundary) shows you've thought through the dependency order, not just proposed splitting arbitrarily. Real examples: "We can tackle this incrementally — one module per sprint"; "Incrementally — starting with the models, then controllers, then views"; "Incremental approach: extract the service layer first, then refactor the controllers once the seams are clear." Options A-C are too vague about what "incremental" means in practice.
5 / 10
You're proposing to write tests before touching any existing code. How do you frame it?
KEY PHRASE: "I'll write tests first to pin the behaviour before we touch anything" This is the textbook characterisation test approach — you write tests to capture the current (possibly buggy) behaviour before refactoring, so any change that breaks the output is detected immediately. "Pin the behaviour" is the precise engineering term for this. The first-person ownership ("I'll write") adds credibility and signals a concrete plan. Real examples: "I'll write a characterisation test suite first to pin the behaviour — then we can safely refactor"; "Tests first to pin current output — then we refactor with confidence." Options B-D are vague aspirations ("at some point", "make sure we have", "would be good") — none signal urgency, ownership, or the right framing.
6 / 10
Context: During a code review of the user-service module, Sarah notices significant duplication across several classes. She wants to suggest refactoring to David, the lead developer. Which of the following is the most appropriate initial comment to make?
Sarah's goal is to initiate a discussion about refactoring. Option 1 dismisses her concerns without engagement. Option 2 directly addresses the issue and proposes a conversation—the most constructive approach. Options 3 and 4 introduce unrelated issues or tasks, derailing the focus on code quality.
7 / 10
Context: Liam is drafting a pull request description for a refactoring of a complex data validation function. He wants to clearly justify the changes to his team. Which of these phrases best communicates the *reason* behind the refactor?
Liam needs to explain *why* the refactor was necessary. Option 1 provides a trivial justification. Option 2 highlights the problem (complexity) and solution (simplified logic), demonstrating the value of the change. Options 3 and 4 lack a substantive explanation of the refactoring's purpose.
8 / 10
Context: Maria is in a Slack channel discussing a large feature being added to a legacy system. The conversation drifts towards whether the codebase should be refactored before proceeding. Which response best addresses this concern?
Maria needs to acknowledge the concern while subtly advocating for refactoring. Option 1 dismisses the importance of code quality. Option 2 provides a balanced response acknowledging the benefits (reduced technical debt) and costs (time investment). Options 3 and 4 are impractical and demonstrate a lack of consideration for long-term maintainability.
9 / 10
Context: Ben is proposing a phased refactoring strategy to his team. He needs to explain the benefits clearly. Which of the following statements best describes this approach?
A phased approach is about managing risk and minimizing disruption. Option 1 describes a 'big-bang' refactor which is often problematic. Option 2 clearly outlines the key benefits: working tests before moving on, reducing risk and limiting impact. Options 3 and 4 are unprofessional or ineffective strategies.
10 / 10
Context: Emily is presenting a proposal to her team about adding automated tests *before* refactoring a particularly complex module. What's the most compelling way to frame this suggestion?
Emily is advocating for a best practice: testing before changing. Option 1 ignores a crucial step in the development process. Option 2 explains *why* tests are valuable – confidence, regression prevention, safety net. Options 3 and 4 represent alternative priorities that don't align with robust software development.
What will I practise in "Refactoring Discussions: Proposing & Justifying Code Improvements"?
This module focuses on Phrasebook — real workplace phrasing you'll use on the job. It contains 10 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 10 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Phrasebook exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around phrasebook — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Phrasebook exercises?
See the Phrasebook hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.