Przejdź do głównej zawartości

Strategie refaktoryzacji

Twój plik serwisu użytkowników rozrósł się do 800 linii. Obsługuje uwierzytelnianie, zarządzanie profilami, preferencje powiadomień i usuwanie kont — wszystko w jednym pliku. Każdy deweloper w zespole go modyfikuje z różnych powodów, konflikty merge są ciągłe, a plik testowy ma 1200 linii ściśle powiązanych przypadków testowych. Wiesz, że trzeba go podzielić, ale ostatnim razem, gdy ktoś próbował dużej refaktoryzacji, zepsuło to trzy inne serwisy i stabilizacja zajęła tydzień.

Refaktoryzacja wspomagana AI rozwiązuje problem “zbyt ryzykowne, żeby ruszać”, czyniąc duże refaktoryzacje przyrostowymi, weryfikowalnymi i odwracalnymi. Kluczem jest rozbicie refaktoryzacji na małe, bezpieczne kroki, gdzie każdy krok jest weryfikowany przez istniejący zestaw testów przed przejściem do następnego.

  • Przyrostowy workflow refaktoryzacji utrzymujący zielone testy na każdym kroku
  • Gotowe prompty do skopiowania dla najczęstszych wzorców refaktoryzacji
  • Strategie refaktoryzacji kodu, od którego zależą inne serwisy
  • Techniki wykorzystania checkpointów Cursora i gita do bezpiecznej pracy

Nigdy nie refaktoryzuj wszystkiego naraz. Zamiast tego:

  1. Uruchom pełny zestaw testów. Potwierdź, że przechodzi. Zatwierdź.
  2. Dokonaj jednej zmiany strukturalnej (wyciągnij funkcję, przenieś plik, zmień nazwę zmiennej).
  3. Uruchom pełny zestaw testów. Jeśli przechodzi, zatwierdź. Jeśli nie przechodzi, napraw konkretne uszkodzenie.
  4. Powtarzaj, aż refaktoryzacja będzie kompletna.

Każdy commit to checkpoint, do którego możesz wrócić. Jeśli krok 7 z 10-krokowej refaktoryzacji pójdzie źle, tracisz tylko pracę z kroku 7.

Podziel duży plik na skoncentrowane moduły, zachowując kompatybilność wsteczną:

Gdy potrzebujesz zmienić sygnaturę funkcji używanej w całej bazie kodu:

The createUser function currently takes 6 positional parameters.
Refactor it to take a single options object.
Before: createUser(email, password, firstName, lastName, role, teamId)
After: createUser({ email, password, firstName, lastName, role, teamId })
Update every caller across the codebase. There are approximately 15 call sites.
Run tests after updating each file to catch any mistakes immediately.
Rename the `getUserData` function to `getUserProfile` everywhere in the codebase.
This includes:
- The function definition in @src/services/user-service.ts
- All imports and call sites
- All test references
- Any string references in route definitions or documentation
Run tests after the rename to verify nothing broke.

Dla refaktoryzacji dotykających wielu plików użyj trybu Plan, aby stworzyć ustrukturyzowany plan przed wykonaniem:

I need to migrate our API from Express middleware pattern to a controller pattern.
Current structure:
- Routes define middleware chains directly
- Business logic is mixed into route handlers
- Validation happens at the route level
Target structure:
- Routes map URLs to controller methods
- Controllers handle request/response
- Services contain business logic
- Validation middleware is applied automatically
Create a detailed plan. For each step, specify:
- Which files to modify
- What the change is
- How to verify it works
Ask me up to 3 clarifying questions before creating the plan.

Przejrzyj plan, dostosuj priorytety, a następnie wykonuj krok po kroku w trybie Agent.

Użyj równoległych agentów do porównania podejść

Dział zatytułowany „Użyj równoległych agentów do porównania podejść”

Dla refaktoryzacji, gdzie istnieje wiele poprawnych podejść, użyj funkcji równoległych agentów Cursora:

  1. Wyślij ten sam prompt refaktoryzacji do dwóch różnych modeli
  2. Każdy pracuje we własnym worktree
  3. Porównaj podejścia obok siebie
  4. Zastosuj to, które jest czystsze i przechodzi testy

Po ukończeniu refaktoryzacji uruchom pełny zestaw weryfikacji przed złożeniem:

Agent zmienia zbyt wiele plików naraz. Krok refaktoryzacji jest zbyt duży. Podziel na mniejsze kawałki. “Przenieś 3 funkcje do nowego pliku” jest lepsze niż “zreorganizuj całą warstwę serwisów.”

Testy nie przechodzą po refaktoryzacji, ale kod wygląda poprawnie. Testy mogą testować szczegóły implementacji zamiast zachowania. Użyj trybu Ask, aby przeanalizować, czy niepowodzenie testu to prawdziwa regresja, czy test wymagający aktualizacji.

Importy się psują po przeniesieniu plików. Upewnij się, że tworzysz eksporty barrel (pliki index.ts), które re-eksportują z nowych lokalizacji. To zachowuje kompatybilność wsteczną podczas przyrostowej aktualizacji importów.

PR-y innych członków zespołu kolidują z refaktoryzacją. Poinformuj zespół o dużych refaktoryzacjach przed rozpoczęciem. Zmerguj refaktoryzację szybko (w małych PR-ach, jeśli to możliwe), aby zminimalizować okno konfliktu.