Learn the vocabulary of a code smell where one small change requires edits scattered across many files.
0 / 5 completed
1 / 5
At standup, a dev mentions that making one small logical change, like adjusting how a discount is calculated, requires editing dozens of scattered classes and files across the codebase instead of touching just one place. What is this code smell called?
Shotgun surgery is exactly this: it is a code smell where making one small logical change, like adjusting how a discount is calculated, requires editing dozens of scattered classes and files across the codebase instead of touching just one place, because the underlying logic was never consolidated. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This one-change-many-scattered-edits pattern is exactly why shotgun surgery makes even small changes slow and risky, since it's easy to miss one of the scattered spots.
2 / 5
During a design review, the team consolidates a discount calculation that was previously duplicated across a dozen files into a single DiscountCalculator class, specifically because a future change to the discount rule will now only require editing one place. Which capability does this provide?
Consolidating the logic here provides a single point of change for a piece of logic, since consolidating the duplicated discount calculation into one class means a future rule change touches exactly one place instead of requiring a scattered edit across a dozen files. Leaving the discount calculation duplicated across a dozen files means every future change risks missing one of the scattered copies. This one-place-to-change behavior is exactly why consolidating scattered logic is the standard fix for shotgun surgery.
3 / 5
In a code review, a dev notices that a small change to how a discount percentage is rounded requires editing the same rounding logic independently in twelve different files, because the calculation was copy-pasted rather than consolidated into a shared place. What does this represent?
This is shotgun surgery, since this one small logical change requires scattered edits across twelve different files instead of touching a single consolidated place. A cache eviction policy is an unrelated concept about discarded cache entries. This one-change-many-files pattern is exactly the kind of smell a reviewer flags once duplicated logic makes even a small change error-prone.
4 / 5
An incident report shows a discount was calculated incorrectly in production because a rounding rule change was applied to eleven of the twelve files that duplicated the calculation, missing the twelfth entirely, since the logic had never been consolidated into a single place. What practice would prevent this?
Consolidating the duplicated discount calculation into a single shared class means a future rule change touches exactly one place instead of requiring a scattered edit across every duplicated copy. Continuing to duplicate the discount calculation across every file that needs it regardless of how often a future change misses one of the scattered copies is exactly what caused the missed update described in this incident. This consolidate-the-logic approach is the standard fix once duplicated logic is confirmed to make a change error-prone.
5 / 5
During a PR review, a teammate asks why the team consolidates duplicated logic into a single class instead of simply maintaining a checklist of every file that needs to be updated whenever the discount rule changes. What is the reasoning?
Consolidating the logic into a single class makes it structurally impossible to miss a copy, since there's only one place left to change, while maintaining a checklist still requires every future editor to remember and correctly execute every item on it, and a missed or outdated checklist entry reproduces the exact same scattered-edit risk. This is exactly why consolidating duplicated logic is the standard fix for shotgun surgery, rather than relying on a checklist to manage the scattering.