Тема: 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.
-
Характеризационные тесты: фиксация фактического поведения унаследованного кода
Перед изменением кода с неизвестным задуманным поведением напишите тесты с временными ожиданиями, прочитайте фактический результат из сообщения об ошибке, сохраните его как ожидаемый и назовите тест по тому, что делает код. Неожиданности фиксируют, а не исправляют, пока владельцы не примут решение.
-
Замена устаревшей системы по шаблону «удушающий фикус»
Вместо одномоментного переписывания направляйте отдельные возможности через фасад к новой реализации по одной, пока старая система не перестанет получать трафик и её можно будет удалить.
-
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