Book Refactoring Guru Nano

OBEY Refactoring.Guru

When to use

Use as a compact always-on bias for safe, smell-driven refactoring during existing-code changes.

Primary bias to correct

Refactoring is not cleanup for its own sake: diagnose one smell, treat it with the smallest behavior-preserving move, verify, then stop.

Decision rules

• Separate structural refactoring from feature and bug behavior; if behavior changes, name and isolate it.
• Diagnose the smell before choosing a technique: symptom, cost, smallest treatment, verification, and stop condition.
• Prefer small named transformations over broad redesign.
• Keep the program runnable and run relevant checks after risky movement, state-flow changes, public API changes, or algorithm replacement.
• Stop when the diagnosed smell is reduced; do not chase new smells unless they block the current change.
• Prefer extraction, naming, movement, inlining, and encapsulation before adding hierarchy, polymorphism, wrappers, or method objects.
• Do not create abstractions from coincidental similarity, random parameter bags, simple conditionals, or speculative future needs.
• Keep behavior with the data it changes unless separation intentionally supports interchangeable behavior.
• Preserve public compatibility when changing signatures, constructors, visibility, hierarchy, or externally reachable code.
• Delete or inline dispensable code only after checking public, generated, reflected, serialized, plugin-facing, framework, and test-only uses.

Trigger rules

• When a method needs comments or local-state reconstruction, extract a named method after checking inputs, outputs, and mutated variables.
• When a class changes for unrelated reasons, extract the responsibility; use subclass/interface only for stable variants or real client subsets.
• When conditionals repeat by type or state, isolate the decision before using polymorphism; leave simple honest conditionals alone.
• When duplicate code appears the third time, refactor unless the similarity is likely to diverge.
• When parameter lists or primitive clumps carry one concept, model the concept; do not pass a huge object to hide dependency.
• When clients navigate chains or internals, hide the delegate or move behavior; remove pass-through middle men that add no policy.
• When null, error code, assertion, value/reference, or association changes are considered, verify semantics before changing structure.

Final checklist

• Smell named?
• Smallest treatment?
• Behavior verified?
• Stop condition reached?
• No hidden feature change?
• No speculative abstraction?