code-refactoring

Replace nested if statements with guard clauses that return early when conditions are not met. This flattens arrow code into a linear sequence of checks, making the happy path clear at the bottom of the function.

Common code smells include long methods doing too much, deeply nested conditionals, primitive obsession where raw strings replace value objects, and feature envy where a method heavily uses another object's data. Each has a standard refactoring pattern.

Avoid refactoring when there are no tests covering the code, when under tight deadlines without a safety net, when the code will be replaced soon, or when you do not understand what the code does. Refactoring without tests risks silent behavior changes.

First ensure tests exist and pass, then make one small refactoring at a time, running tests after each change. Commit frequently so you can revert easily, and review the diff to confirm only structure changed, not behavior.

Define a common interface with the varying method, then create a class per type implementing that interface. Each class holds its own logic, eliminating the switch and making new types easy to add without modifying existing code.