Jednostka 8 / 12

Refaktoryzacja i zarządzanie długiem technicznym

Zyski:

  • Możliwość skonfigurowania testowej siatki bezpieczeństwa, która przechwytuje bieżące zachowanie przed refaktoryzacją
  • Możliwość poproszenia sztucznej inteligencji o małe, jednoetapowe transformacje zachowujące zachowanie i walidacji każdego kroku
  • Umiejętność identyfikowania i ustalania priorytetów długu technologicznego w kontekście biznesowym

Refaktoryzacja poprawia wewnętrzną strukturę kodu bez zmiany jego zewnętrznego zachowania: czyni go bardziej czytelnym, prostszym i łatwiejszym w utrzymaniu. Z kolei dług techniczny to kompromis projektowy dokonany w imię szybkiego rozwiązania i spłacany „z odsetkami” w czasie – każdy zakątek, który dzisiaj skrócisz, jutro wróci jako spowolnienie lub błąd. Sztuczna inteligencja to potężny asystent, który przyspiesza powtarzalne i mechaniczne zadania refaktoryzacji; Istnieje jednak jedna złota zasada refaktoryzacji, której sama sztuczna inteligencja nie może zagwarantować: zachowanie nie może się zmienić.

W tej części uczymy się, jak przeprowadzić bezpieczną refaktoryzację za pomocą sztucznej inteligencji: małe i odwracalne kroki, ochrona za pomocą testów, wykrywanie zapachów kodu i ustalanie priorytetów długu technicznego. Najważniejszym punktem jest to, że to pozytywne wyniki testów, a nie słowa sztucznej inteligencji, dowodzą, że zachowanie zostało zachowane.

Złota zasada refaktoryzacji: zachowanie pozostaje stałe

To, co sprawia, że refaktoryzacja jest niebezpieczna, to nieświadoma zmiana zachowania podczas mówienia „Poprawiam się”. Porzucenie przypadku Edge podczas upraszczania warunku, łamanie kolejności podczas przekształcania pętli, pomijanie efektu ubocznego podczas dzielenia funkcji — wszystko to tworzy „czysto wyglądający”, ale zepsuty kod.

Dlatego testowanie jest warunkiem wstępnym refaktoryzacji: przed zmianą musisz mieć testy, które wychwytują istniejące zachowanie. Testy te stanowią „sieć bezpieczeństwa”; Jeśli przypadkowo coś zepsujesz podczas refaktoryzacji, pękną i cię ostrzeżeją. Jeśli nie masz testów, napisz najpierw testy, które naprawią istniejące zachowanie (jak dowiedzieliśmy się w części 5) — w tym miejscu sztuczna inteligencja może przyspieszyć.

Uwaga: refaktoryzacja wspomagana sztuczną inteligencją bez sieci testowej jest jednym z najbardziej podstępnych źródeł błędów. Łatwo powiedzieć „zachowałem to zachowanie”; Dowodem jest to, że te same testy przechodzą przed i po zmianie.

Krok po kroku: bezpieczny przebieg refaktoryzacji

  1. Załóż siatkę zabezpieczającą. Niech zostaną przeprowadzone testy, które wychwytują bieżące zachowanie kodu, który będziesz refaktoryzować; Jeśli nie, zapisz je najpierw (i zobacz, jak zostaną zrealizowane).
  2. Nazwij zapach. Co poprawiasz i dlaczego? „Ta funkcja robi 3 rzeczy”, „ta sama logika powtarza się w 4 miejscach”, „nazwy wprowadzają w błąd”.
  3. Poproś o małe, jednoetapowe kroki. Poproś AI o pojedynczą transformację (np. po prostu „podziel tę funkcję na pół”), a nie przepisz cały plik.
  4. Uruchom testy. Po każdym kroku. Jeśli jest zielony, kontynuuj, jeśli jest czerwony, zabierz go z powrotem.
  5. Przeczytaj Różnicę. Potwierdź wiersz po wierszu, że zmiana rzeczywiście polega na zachowaniu zachowania; Stwierdzenie, że sztuczna inteligencja to „tylko struktura”, może wystąpić poślizg logiczny.
  6. Połączyć na małe kawałki. Duże jednorazowe żądania PR dotyczące refaktoryzacji są zarówno ryzykowne, jak i niepodlegające przeglądowi.

Trzy mini etui

Przypadek 1 — funkcja 220 linii jest bezpiecznie podzielona. Jeden zespół miał funkcję przetwarzania zamówień obejmującą 220 linii. Napisano pierwszych 14 testów (przy pomocy AI), które rejestrowały aktualne zachowanie, wszystkie zdały egzamin. Następnie funkcja została krok po kroku podzielona przez AI na 5 mniejszych funkcji; Po każdym etapie przeprowadzano testy. Dwa testy zostały złamane w jednym kroku – sztuczna inteligencja przegapiła zwrot w przypadku Edge. Testy natychmiast to wychwyciły i naprawiły. Bez sieci błąd mógłby przejść aż do produkcji.

Przypadek 2 — Katastrofa bez sieci testowej. Inny programista „oczyścił” moduł obliczania daty, który nie miał testów z AI. Kod wyglądał lepiej, ale niepoprawnie obliczał rok przestępny; Błąd pojawił się dwa tygodnie później w wyniku skargi klienta. Strata znacznie przewyższyła czas zaoszczędzony na refaktoryzacji. Lekcja: refaktoryzacja bez testowania to ryzyko.

Przypadek 3 – Priorytetyzacja długu technicznego. Jeden zespół przyznał AI około 30 punktów „możliwych do ulepszenia” i każdy z nich ocenił na osi „częstotliwość zmian × ryzyko × wysiłek”. W wynikowej tabeli brzydki moduł, którego rzadko dotykano, miał w rzeczywistości niski priorytet, podczas gdy moduł o średniej złożoności, który często się zmieniał, miał wysoki priorytet. Zespół skierował swoją energię we właściwe miejsce.

Cztery szablony do kopiowania

Wykrywanie zapachu kodu i ustalanie priorytetów:

Lista kandydatów do refaktoryzacji „pachnie” w tym kodzie: długa funkcja, powtórzenie (DRYViolation), myląca nazwa, warunek głęboko zagnieżdżony, ukryty efekt uboczny, magiczna liczba. Dla każdego: lokalizacja, przyczyna problemu, sugerowany mały krok, szacowane ryzyko (niskie/średnie/wysokie). NIE ZMIENIAJ jeszcze kodu, po prostu planuj.{{code}}

Jednoetapowa transformacja zachowująca zachowanie:

PO PROSTU zrób to: {{pojedyncza konwersja, np. Podziel tę funkcję na 3 mniejsze nazwane funkcje}}. ZMIEŃ widoczne zachowanie, podpis i zwracane wartości. Napisz w jednym zdaniu, dlaczego wszystko, co zmieniłeś, powoduje zachowanie tego samego zachowania.{{code}}

Siatka bezpieczeństwa przed refaktoryzacją (testowanie charakterystyki):

Napisz testy, które przechwytują BIEŻĄCE zachowanie tej funkcji (poprawne lub nie); celem jest wyłapanie zmiany zachowania podczas refaktoryzacji. Uwzględnij wpisy typowe + krawędziowe. Zapisz oczekiwania na podstawie bieżącego wyniku funkcji.{{funkcja}}

Generowanie rejestru długu technicznego (backlogu):

Wpisz następującą listę zapachów do tabeli priorytetów: substancja, dotknięty obszar, częstotliwość zmian (moja wiedza: {{...}}), ryzyko, szacowany wysiłek, zalecany priorytet. Umieść te o dużym wpływie i niskim wysiłku na górze. {{lista_zapachów}}

Słaba zachęta/silna zachęta

Słabe: „Wyczyść ten kod i ulepsz go”.
Strong: „Podziel tę 90-liniową funkcję na 3 mniejsze funkcje z pojedynczą odpowiedzialnością, bez zmiany jej zewnętrznego zachowania i podpisu. Zachowaj skutki uboczne (zapisy w DB) w bieżącej kolejności. Mam testy, zachowanie powinno pozostać takie samo. Podaj różnicę i wyjaśnij jednym zdaniem, dlaczego każdy podział zachowuje zachowanie. [kod]”

Potężna wersja; Wymaga jednej konkretnej transformacji, wyraźnie narzuca ograniczenia dotyczące zachowania i podpisu oraz wymaga uzasadnienia. Niejasne żądania, takie jak „rób lepiej”, prowadzą do niekontrolowanych i ryzykownych zmian.

Typ refaktoryzacji

Niezawodność sztucznej inteligencji

Warunek wstępny

zmienić nazwę

wysoki

Czy zakres jest prawidłowy?

Podział funkcji

średnio-wysoki

Testnet jest koniecznością

Udostępnianie powtórzeń

średni

Różnice w zachowaniu mogą być ukryte

Zmiana algorytmu/struktury

niski

Rozbudowane testy + weryfikacja przez człowieka

Przebudowa architektoniczna

niski

Kierowany przez człowieka, wspierany przez sztuczną inteligencję

Zarządzanie długiem technicznym, a nie jego resetowanie

Dług technologiczny nie jest taki zły; Czasami świadome zaciąganie pożyczek (w celu spłaty) jest właściwą decyzją. Celem nie jest wyeliminowanie długu, ale uczynienie go widocznym i możliwym do zarządzania. Sztuczna inteligencja szybko wykrywa i ustala priorytety zadłużenia, ale decyzja „który dług należy spłacić, a który porzucić” wymaga kontekstu biznesowego: jak często ten moduł się zmienia, ilu osób to dotyczy, jakie jest ryzyko? Decyzję tę podejmuje zespół, który zna bazę kodu i produkt; AI po prostu wyjaśnia opcje.

Wskazówka: Trzymaj PR refaktoryzacyjne oddzielnie od PR, które obejmują zmianę zachowania. Możliwość powiedzenia „ten PR to tylko refaktoryzacja, zachowanie jest takie samo” ułatwia zbadanie i pozwala szybko zawęzić przyczynę, jeśli pojawi się problem.

Typowe błędy

  • Refaktoryzacja bez sieci testowej. Nie pozostaje Ci nic, co mogłoby udowodnić, że zachowanie zostało zachowane.
  • Oznacza to „wyczyść cały plik”. Duże, niekontrolowane zmiany ukrywają błąd i nie można ich sprawdzić.
  • Akceptowanie różnic bez czytania. Sztuczna inteligencja mogła porzucić logikę, mówiąc „tylko struktura”.
  • Mylenie refaktoryzacji ze zmianą zachowania. Wykonanie obu w tym samym PR uniemożliwia śledzenie pierwotnej przyczyny.
  • Próbuję naprawić każdy zapach. Brzydki kod, który rzadko się zmienia, ma często niski priorytet; Przydzielaj energię miejscu, które często się zmienia.

Podsumowując

Jedyną zasadą refaktoryzacji jest to, że zachowanie pozostaje stałe, a dowodem na to są testy. Sztuczna inteligencja skutecznie wykrywa zapach kodu, jednoetapowe transformacje i ustala priorytety długu technicznego; ale musisz ustawić siatkę bezpieczeństwa, przeprowadzić testy i odczytać różnicę po każdym kroku. Podejmuj małe, odwracalne kroki; odróżnić refaktoryzację od zmiany zachowania; i pozwól zespołowi znającemu kontekst biznesowy zdecydować, który dług spłacić.

Zadanie aplikacji

Wybierz funkcję z bazy kodu, która wydaje Ci się długa lub złożona. Najpierw wydrukuj testy, które wychwytują jego obecne zachowanie za pomocą szablonu „siatki bezpieczeństwa” i sprawdź, czy wszystkie przeszły pomyślnie. Następnie przeprowadź refaktoryzację funkcji w jeden sposób (np. podzielenie na pół) przy użyciu wzorca „jednoetapowa transformacja zachowująca zachowanie” i uruchom testy ponownie. Jeśli test się nie powiedzie, dowiedz się dlaczego; Jeśli w ogóle się nie zepsuje, przeczytaj różnicę linia po linii, aby potwierdzić, że zachowanie rzeczywiście zostało zachowane.

lista kontrolna

  • [ ] Wiem, że refaktoryzacja nie powinna zmieniać zachowania i istnieją testy, które to potwierdzają.
  • [ ] Tworzę siatkę bezpieczeństwa, która wychwytuje bieżące zachowanie przed refaktoryzacją.
  • [ ] Chcę małych, jednoetapowych transformacji AI, a nie dużych jednorazowych zmian.
  • [ ] Po każdym kroku uruchamiam testy i odczytuję różnicę.
  • [ ] Refaktoryzuję PR oddzielnie od PR zmiany zachowania.
  • [ ] Priorytetowo traktuję dług techniczny w kontekście biznesowym, a nie ślepo próbuję go wyzerować.