Тема: refactoring
-
Refactoring in small, verified steps
Refactoring changes structure without changing behaviour; doing it in tiny steps with tests green between steps, and separating refactoring commits from behaviour changes, keeps it safe and reviewable.
-
Recognising code smells before refactoring
Code smells are surface symptoms (long methods, large classes, feature envy, shotgun surgery, primitive obsession) that suggest a deeper design problem; naming them gives a vocabulary for review and a trigger for refactoring.
-
Refactoring in kleinen, geprüften Schritten
Refactoring ändert die innere Struktur, nicht das beobachtbare Verhalten. Ein benanntes Refactoring aus dem Katalog nach dem anderen, Tests nach jedem Schritt grün, bei Rot rückgängig statt vorwärts debuggen, Struktur- und Verhaltensänderungen in getrennten Commits – so bleibt die Arbeit sicher und in Minuten prüfbar.
-
Characterisation tests: pinning what legacy code actually does
Before changing code whose intended behaviour is unknown, write tests with placeholder expectations, read the real output from the failure, record it as the expectation and name the test after what the code does; surprises are logged, not fixed, until the owners decide.
-
Replacing a legacy system with the strangler fig pattern
Instead of a big-bang rewrite, route individual capabilities through a facade to a new implementation one at a time, until the old system carries no traffic and can be removed.
-
Testdaten mit Buildern aufbauen: gültige Vorgaben, benannte Abweichungen
Ein Testdaten-Builder liefert für jede Entität ein gültiges Standardobjekt und lässt den Test nur die Felder setzen, auf die seine Aussage ankommt. So liest man im Test, was zählt, und eine neue Pflichtspalte ändert eine Stelle statt hundert Tests. Das Vorgehen grenzt sich von geteilten Fixtures und der Object Mother ab, deren enge Kopplung Martin Fowler beschreibt.
-
Test data builders with defaults reduce test breakage when a domain object changes
Hypothesis: suites that build objects through builders, where every field has a valid default and a test sets only the fields it asserts on, need fewer test edits per schema or constructor change than suites relying on shared fixtures or object mothers with canned instances.
Машиночитаемо: JSON