Refaktoryzacja bez paraliżu projektu

Wielki przegląd ("zroóbmy refactoring całego legacy") niemal nigdy się nie udaje. Oto jak wplatać porządkowanie kodu w codzienną pracę.

Dlaczego "wielki refactoring" umiera

Klasyczny scenariusz: zespół dostaje tydzień na "posprzątanie". Po tygodniu:

• biznes pyta kiedy wracają feature,
• merge z mainem to ból (wszystko się rozjechało),
• nikt nie wie czy to "lepsze" czy "rorwane".

Refactoring jako osobna epic to anty-wzorzec.

Refactoring w przepływie (flow refactoring)

Zamiast wielkich przejść — małe, ciągłe poprawki:

• Boy Scout Rule: zostaw kod lepszym niż zastałeś.
• Sprzątaj przy okazji: touchasz funkcję? Zrób jeden mały krok czystości.
• Type-driven: zmiana typu wymusza lokalny porządek.

Efekt: po kwartale kod jest o 30% czystszy, a nikt nie ogłaszał "refactoringu".

Jak nie zabić tempa

1. Nie przerywaj feature — refactoring idzie obok, nie zamiast.
2. Małe PR-y — 50 linii refaktoryzacji przechodzi review w 10 min.
3. Testy jako sieć bezpieczeństwa — jak masz suite, refactoruj śmiało.
4. Characterisation tests — dla legacy bez testów: napisz testy opisujące obecne zachowanie, potem refaktoruj.

Narzędzia które pomagają

• ruff / mypy — automatyczna higiena w pre-commit.
• Coverage diff — blokuj spadek pokrycia w PR.
• Branch-by-abstraction — duże zmiany API robisz przez warstwę pośrednią, by nie łamać callersów naraz.

Podsumowanie

Refactoring nie jest projektem. Jest nawykiem. Kto zrobi go częścią Definition of Done, ten nie potrzebuje "wielkich przeglądów" — bo kod nigdy nie zdąży się zepsuć.