Justifying Refactoring — Vocabulary and Business Language
Learn vocabulary for justifying refactoring decisions: business case, risk language, timing, and return on investment.
0 / 10 completed
1 / 10
What is the 'boy scout rule' in refactoring vocabulary?
The Boy Scout Rule (Robert C. Martin): 'Always leave the campground cleaner than you found it.' Applied to code: each commit should leave the code slightly better — rename a variable, extract a method, remove a comment. Incremental improvement avoids the need for large, risky refactoring projects.
2 / 10
How do you justify a refactoring to non-technical stakeholders?
Non-technical stakeholders respond to business impact, not code quality. Effective justification: 'Feature X is taking 3x longer than it should because of [module]. Refactoring it will reduce future feature costs in this area by an estimated 60% and reduce the risk of [bug type].' Specific, measurable, business-outcome framing.
3 / 10
What is 'opportunistic refactoring' in software engineering vocabulary?
Opportunistic refactoring (Fowler) means improving code while working in an area for another reason — 'I'm adding this feature anyway, let me extract this method while I'm here.' It distributes refactoring effort across the development flow and avoids the need for large dedicated refactoring sprints.
4 / 10
What does 'strangler fig pattern' mean in refactoring vocabulary?
Strangler Fig (Fowler, inspired by the strangler fig tree): build the new system alongside the old, routing new functionality to the new system while old functionality gradually migrates. The old system is 'strangled' until it handles nothing and can be deleted. Used for high-risk legacy migrations.
5 / 10
What is 'refactoring debt' and how does it differ from 'technical debt'?
Technical debt is broader: rushed decisions, missing tests, poor architecture. Refactoring debt is the tracked, acknowledged subset: 'We know Module X needs to be extracted into a service — it's in the backlog.' Making debt visible in a debt registry (JIRA epic, ADR) separates it from vague technical debt conversations.
6 / 10
Sarah (Senior Developer) left this comment on a code review:
"This `calculate_order_total` function is getting messy. I'm refactoring it to separate the discount calculation logic. It'll make testing easier and improve readability."
This is a good example of justifying refactoring. Sarah used language that highlights the *benefits* – easier testing and improved readability – which is crucial when communicating with colleagues. The key is to frame the change not just as 'fixing code,' but as improving the system's maintainability and reducing future issues. Options A, C, and D all miss this core element.
7 / 10
Mark (Product Manager) needs to explain a refactoring decision to the marketing team. Which of the following statements best reflects how he should approach the conversation?
A) "We've updated the API endpoint to improve performance by 15%."
B) "We've streamlined the codebase for better maintainability, reducing the risk of future bugs and simplifying development."
C) "We've rewritten the core logic using a more efficient algorithm."
D) "The refactoring involved changing the data structures used in the system."
Product Managers need to translate technical changes into business value. Option B emphasizes maintainability and reduced risk – concepts that are directly relevant to product stability and future development efforts. Options A, C, and D are too granular for a non-technical audience; they focus on specific implementation details rather than the broader impact.
8 / 10
You're reviewing a PR description that states: 'Refactored user authentication flow using OAuth 2.0.' Which of the following is the MOST effective way to improve this description?
A) Simply stating 'Implemented OAuth 2.0 for authentication'.
B) Adding a sentence explaining *why* OAuth 2.0 was chosen, such as 'Improves security and reduces server load by delegating authentication.'
C) Listing all the technical changes made during the refactoring.
D) Focusing on the performance improvements achieved through the new implementation.
A good PR description should explain *why* the change was made. By adding context – in this case, explaining the benefits of OAuth 2.0 (security and reduced server load) – you provide stakeholders with a clearer understanding of the value being delivered. Option A is too terse; Option C is overly technical and Option D focuses on a potential outcome rather than the rationale.
9 / 10
David (Lead Engineer) uses the 'strangler fig pattern' to migrate a legacy system. He's explaining this approach to his team:
"We're building a new service that mimics the old one's functionality, gradually replacing its components until we can decommission the original."
The Strangler Fig pattern is about incremental change. David's description captures this perfectly: building a new service that *mirrors* the old one while gradually replacing its components. The key is understanding that it's not about a single, massive rewrite, but a phased transition. Options A and C are too technical; Option D provides a specific visual aid rather than explaining the underlying concept.
10 / 10
Elena (Junior Developer) is discussing 'refactoring debt' with her mentor. Elena says: 'Refactoring debt is just like regular technical debt – it's something we should always be paying down.'
What is the MOST accurate response from her mentor?
While refactoring debt *is* debt, it arises from shortcuts taken during refactoring itself – for example, quickly fixing a bug without fully understanding the surrounding code. This creates new technical debt that needs to be addressed later. The key difference is its origin: regular technical debt stems from initial design choices; refactoring debt comes from poorly executed refactorings. Options A and C are incorrect; Option D suggests an unnecessary level of detail.
What will I practice in "Justifying Refactoring — Vocabulary and Business Language"?
This is a Refactoring Language exercise set. It walks through 10 scenario-based multiple-choice questions built around real usage of refactoring language terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 10 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the refactoring language vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Refactoring Language exercises?
See the Refactoring Language exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — refactoring language vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.