Smells & Refactoring

Don't rely on willpower: automate style, gate only newly changed code so quality can only improve, target effort using change-frequency data, give every area an owner, and make small cleanup commits normal and welcome in review.

Only make edits a tool or the compiler can verify: automated refactorings, preserving method signatures, moving code without retyping, one goal per edit, small steps compiled and run often. For big restructurings, work in small always-shippable increments, route new work through a new implementation, and keep the old path live until traffic is moved.

Do it in small, always-green steps: create the new class, move one field or method at a time while the old class delegates to it, run the tests each time, and only remove the delegation once every caller has migrated. Never move everything at once.

Break it into many small commits that each keep the build green. Use the Mikado Method to map prerequisites by trying the change, noting what breaks, reverting, and doing the prerequisites first. Use parallel change — add the new form, migrate callers, remove the old — so old and new coexist while others keep working.

Fix a smell when it makes upcoming work harder. Weigh how often the code changes, how risky it is, and whether tests protect it. Rarely-touched, stable, or soon-to-be-deleted code can keep its smells — refactoring it costs real money and buys nothing.