Narrating Code Changes — Before and After Vocabulary
Learn vocabulary for describing code changes in pull requests and reviews: what changed, why, and how it improves the code.
0 / 10 completed
1 / 10
What is the purpose of a 'refactoring PR description' and what should it include?
A refactoring PR description should cover: WHAT changed (e.g., extracted PaymentProcessor class from OrderService), WHY (OrderService had 15 responsibilities and 800 lines), behavior contract (no behavior changes — all existing tests pass), and verification steps (run test suite, check integration tests).
2 / 10
What does 'no behavior change' mean in a refactoring PR?
'No behavior change' is the core contract of refactoring: the external observable behavior (output, side effects, API) is identical — only the internal implementation improved. This is proven by having a complete test suite that passes before and after the refactoring.
3 / 10
How do you describe an 'Extract Method' refactoring in a PR?
Precise refactoring language: 'Extracted validatePaymentDetails() from processOrder() — this isolates payment validation logic, allows independent testing, and reduces processOrder() from 80 to 35 lines.' Naming the refactoring type, source, destination, and improvement helps reviewers understand intent and scope.
4 / 10
What is the 'explain the why, not the what' principle in code narration?
Good PR descriptions (and comments) explain WHY: 'We use a two-phase commit here because the payment and inventory systems must succeed or fail atomically — a naive single-phase approach caused split-brain incidents in Q2 2023.' The WHAT is visible in the diff — the WHY is not.
5 / 10
What is 'regression risk' in a refactoring context?
Regression risk in refactoring: structural changes may inadvertently alter behavior. Mitigation: comprehensive test suite coverage before refactoring, small incremental refactoring steps (not giant rewrites), CI pipeline that catches regressions, and characterization tests for legacy code without tests.
6 / 10
Liam, a senior developer, left this comment on your PR:
"This change introduces a new `get_user_profile` function. Please explain the reasoning behind this addition and how it integrates with the existing user authentication flow."
The key here is focusing on the 'explain the why' principle. Liam isn't interested in the technical details of the function itself; he wants to understand the business need that prompted this change. A purely technical response misses the crucial context and justification for the addition. Option D is a valid approach, but not as direct as stating the reasoning.
7 / 10
You're drafting a Slack message to your team about a refactoring you've completed. A teammate asks: 'What did you change?' Which response best reflects good practice?
The most effective response highlights the *impact* of the refactoring – streamlining and improving readability. Simply stating what was changed (the code itself) isn't helpful for your teammates to understand the value you've added. It demonstrates an understanding of the broader goals of refactoring: reducing complexity, improving maintainability, and minimizing future bugs.
8 / 10
You're writing a PR description for a change that extracts a method from a larger function. Which of the following statements is MOST accurate?
The core purpose of an Extract Method refactoring is to create a reusable component. Describing it simply as 'breaking up a long function' doesn't convey this benefit. Highlighting code duplication reduction and modularity accurately reflects the value proposition of this common refactoring technique. Options 3 and 4 are related but don't fully capture the *why*.
9 / 10
Maya, during a code review, says: 'This PR doesn't introduce any new behavior.' What does she *really* mean?
'No behavior change' signifies that the refactoring didn't alter the *outcome* of the system. It means the same inputs still produce the same outputs – a critical consideration in minimizing regression risk. Option 2 is close but emphasizes structure over functionality. Option 3 and 4 are irrelevant to the core meaning.
10 / 10
You've refactored a complex data processing pipeline using a series of Extract Method changes. A tester reports a bug that was *not* present in the original code. What is the MOST likely cause?
Despite careful planning and Extract Method refactorings, regression risk remains. These changes can introduce unexpected interactions or expose latent dependencies that weren't apparent in the original codebase. This highlights the importance of thorough testing *after* refactoring, even when aiming for 'no behavior change'.
What will I practice in "Narrating Code Changes — Before and After Vocabulary"?
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.