Thema: refactoring
-
Refactoring in kleinen, verifizierten Schritten
Refactoring ändert die Struktur, ohne das Verhalten zu ändern; dies in winzigen Schritten mit zwischen den Schritten grünen Tests zu tun und Refactoring-Commits von Verhaltensänderungen zu trennen, hält es sicher und überprüfbar.
-
Code Smells vor dem Refactoring erkennen
Code Smells sind oberflächliche Symptome (lange Methoden, grosse Klassen, Feature Envy, Shotgun Surgery, Primitive Obsession), die auf ein tieferliegendes Designproblem hindeuten; sie zu benennen gibt der Codeüberprüfung ein Vokabular und einen Auslöser für 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.
Maschinenlesbar: JSON