Code Refactoring Language Exercises

Extract Method is a refactoring pattern where you take a block of code that can stand alone and move it into a new named method or function. In a pull request comment you might write: "I'd suggest extracting lines 42–58 into a separate calculateDiscount() method — it has a single responsibility and would make the main flow easier to read." Naming the pattern helps teammates understand your intent without reading the full explanation.

A code smell is a surface indicator that a deeper design problem may exist — it is a diagnostic term, not an insult. Frame it constructively: "There's a code smell here — the method has seven parameters, which often signals that we need to introduce a parameter object or split the method." Using established vocabulary from Martin Fowler's refactoring catalogue keeps the conversation technical and objective rather than personal.

Focus on business outcomes rather than technical elegance: "This section of the codebase has a high change failure rate — every time we touch it we introduce a regression. Investing two story points to clean up the conditional logic will reduce our bug rate in this area and make future feature work faster." Useful phrases include: reduce cognitive load, lower the bus factor, pay down technical debt, and improve maintainability.

Rename refactoring (sometimes called Rename Symbol) is a safe, automated refactoring that uses the IDE or language server to update every reference to a symbol simultaneously, including imports, tests, and documentation comments. Manually changing a name risks missing a reference. In a PR description you might write: "Renamed UserRecord to UserProfile via IDE rename refactoring — all 34 references updated automatically, no manual edits."

Move Method means taking a method from one class and placing it in the class that owns the data it primarily operates on. You can explain it as: "The calculateShippingCost() method is in the Order class but it only uses properties from the Cart. It belongs in Cart, so we're moving it there. This reduces coupling between the two classes and makes each class more cohesive." The goal is to align methods with the data they depend on.

Common categories include: deliberate debt (a conscious shortcut taken under time pressure with a plan to repay), inadvertent debt (poor design discovered only later), reckless debt (cutting corners without awareness of the cost), and prudent debt (a calculated trade-off that was worth making). In team communication: "This is prudent, deliberate debt — we chose a simpler implementation to ship on time, and we've logged a ticket to revisit it in Q2."

This refactoring replaces a chain of if/else or switch statements that branch on a type with separate subclasses or strategy objects. Narrative example for a PR: "Previously, PaymentProcessor had a 40-line switch statement branching on payment method type. I replaced it with a PaymentStrategy interface and three concrete implementations. Adding a new payment type now requires no changes to the existing switch logic — it's open for extension and closed for modification."

The Strangler Fig Pattern (coined by Martin Fowler) describes incrementally replacing a legacy system by building new functionality alongside the old one, routing traffic to the new code, and gradually "strangling" the old system until it can be removed. Communication phrase: "We're applying the strangler fig pattern to the monolith — new order processing logic is being written in the new service, and we're migrating endpoints one by one rather than doing a big-bang rewrite."

A pure refactoring commit should make clear that behaviour is unchanged. Use the refactor: prefix in conventional commits and name the specific pattern: refactor: extract AuthTokenValidator from AuthService, refactor: rename UserRecord to UserProfile across codebase, refactor: replace payment type switch with PaymentStrategy. Always state "no behaviour change" or "no functional change" so reviewers know the change is safe to approve without testing every code path.

Dead code is code that is never executed — unreachable branches, unused functions, deprecated feature flags that are always false. Useful phrases: "This handler is never called — I traced all entry points and confirmed there are no live references," "Removing the feature flag guard since the experiment concluded 8 months ago and the flag is permanently enabled," or "I deleted the legacy import path; the deprecation notice was added in v3.2 and it has had zero callsites since v4.0."