You must restructure code that has no tests and cannot cheaply get any. What disciplines make editing safe(r) without a safety net, and how do you sequence a large legacy restructuring across a team?

## Why 'be careful' is not a strategy Hand editing untested code fails because human attention is unreliable and the feedback loop is absent. The remedy is to change the **class of edits** you permit yourself: an edit whose correctness follows from how it was performed does not need a test to justify it. ## Disciplines for safe editing without tests **1. Automated refactorings, trusted but verified.** IDE operations (Rename, Extract Method, Move, Inline, Change Signature) apply mechanical transformations across the codebase. They are far safer than manual edits, but not infallible: some IDE refactorings change behaviour in edge cases (e.g. extracting code that captures a variable, or renames that collide with reflective/string-based lookups). Feathers' advice: know which refactorings your tool performs safely, avoid combining several before checking, and never accept a refactoring you did not read the preview of. **2. Preserve signatures.** When extracting or moving code, keep parameter lists identical and pass whole parameter objects. The classic error — swapping two same-typed arguments — is invisible to the compiler and to review. If the signature never changes, that error cannot occur. **3. Move, do not retype.** Cut and paste bodies; retyping introduces transcription errors that look plausible. **4. Lean on the compiler — and know its blind spots.** In statically typed languages you can weaponize the compiler: rename a member to a nonsense name to enumerate all users, or make a field private to find leaks. But the compiler cannot see reflection, dependency-injection wiring by name, serialization formats, ORM column mappings, dynamic proxies, string-keyed configuration, or callers in other repositories. Enumerate those explicitly before relying on "it compiles". **5. Single-goal editing.** One purpose per session. Mixing cleanup with a behaviour change means that when something breaks you cannot bisect intent — and reviewers cannot either. **6. Pair programming / hyper-aware review.** Two people watching a mechanical transformation is the cheapest substitute for a test. **7. Scratch refactoring.** When you cannot understand the code, refactor it aggressively — rename, extract, delete branches — purely to *learn*, then `git reset --hard`. Value is the understanding, not the diff; because it is thrown away, risk is zero. **8. Preparatory refactoring.** Restructure to make the intended change easy, then make the easy change, in separate commits ("make the change easy, then make the easy change"). This keeps every commit reviewable and revertable. **9. Provisional safety nets when tests are impossible.** Even without unit tests you can often add: a golden-master over the batch output, a canary on production metrics, a feature flag, or shadow/parallel execution comparing old and new results. These are coarse, but far better than nothing. ## Sequencing a large restructuring **Mikado Method.** Attempt the goal naively; observe what breaks; **revert**; record the prerequisite as a node in a graph; recurse. You end with a dependency graph whose leaves are small, independently shippable changes, and you build upward. The disciplined revert is the point — the repository is never left in a broken half-migrated state. **Branch by abstraction.** Introduce an abstraction over the thing being replaced, migrate callers to it, implement the new version behind it, switch, then delete the old implementation. Everything happens on trunk in small merges, avoiding a long-lived branch that diverges. **Strangler fig.** Put a facade/router in front of the legacy component. Route a slice of behaviour to a new implementation; grow the routed set; delete the legacy path when its traffic reaches zero. Naturally incremental and always revertable at the router. **Parallel run / shadow comparison.** For high-stakes logic (pricing, tax, risk), run old and new for the same input, serve the old result, and log discrepancies. This creates a characterization test from production traffic — the most faithful possible input distribution — at the cost of double compute and care with side effects (the shadow path must not write or charge). **Explicit deletion step.** Migrations that never delete the old path leave permanent double maintenance. Make removal a scheduled, tracked deliverable with traffic-based exit criteria. ## Organisational disciplines - **Ratchet, do not crusade.** Coverage-on-changed-lines as a gate makes the untested region shrink monotonically without funding a rewrite; a whole-codebase coverage target does not. - **Boy Scout rule with limits.** Leave code better than you found it, but cap incidental scope so reviews stay readable and revert stays possible. - **Do not rewrite from scratch by default.** A rewrite discards embedded knowledge — years of edge cases and bug fixes — and requires the old system to stop changing, which it will not. Rewrites are justified mainly when the platform is unsupportable or the domain has genuinely changed. - **Read-only phase first.** Before any edit, spend explicit time on comprehension: effect sketches, notes on the mess, and scratch refactorings. Cheaper than a wrong restructuring. ## Edge cases - **Dynamic languages** lose the compiler crutch entirely; type annotations plus static analysis partially restore it, and characterization tests become correspondingly more valuable. - **Reflection/DI-heavy frameworks** silently break on rename — grep for the class/method name as a string before renaming. - **Serialized and persisted data** encode structure: renaming a field can break stored records, message payloads, or database mappings, and those failures appear long after deploy. - **Cross-repository callers** are outside the compiler's view; treat them as a public API with deprecation windows.