Zespół dziedziczy moduł rozliczeniowy, którego nikt w pełni nie rozumie. Nie ma w nim testów chroniących istniejące zachowania. Proponowany jest sprint w celu jego „uporządkowania”, a plan zakłada przepisanie rdzenia w nowej strukturze. Nikt nie wie, skąd będzie wiedział, że nowa wersja nadal prawidłowo nalicza opłaty klientom.
To przykładowy scenariusz, a nie udokumentowany incydent. Opisuje on lukę, którą musi wypełnić projekt szkoleniowy z zakresu refaktoryzacji: inżynierowie, którzy widzą, że kod jest chaotyczny, ale nie potrafią jeszcze zaplanować ograniczonej poprawy i wykazać, że zachowanie zostało zachowane.
Ten przewodnik jest przeznaczony dla liderów ds. wdrażania rozwiązań inżynieryjnych i menedżerów ds. inżynierii. Obejmuje on opisywanie problemów z wydajnością, diagnozowanie luk, przygotowanie i praktykę projektową, analizę przypadku oraz ocenę, czy umiejętności przekładają się na praktykę. Dotyczy on projektowania szkoleń. Kod, testy i reguły w programie powinny zostać zweryfikowane przez doświadczonych inżynierów na Twoim własnym stosie.
Czym jest projekt szkoleniowy w zakresie refaktoryzacji?
Projekt szkoleniowy z refaktoryzacji to ustrukturyzowana praca nad starszym kodem, której celem jest zarówno budowanie możliwości, jak i ulepszanie kodu. Uczestnicy planują niewielką, ograniczoną zmianę, chronią istniejące zachowanie za pomocą testów, ulepszają projekt małymi krokami i pokazują dowody na to, że nic nie jest zepsute. Kod staje się lepszy, a co ważniejsze, inżynierowie ćwiczą swoją wiedzę, której będą potrzebować, na rzeczywistym długu technicznym.
Szybkie fakty
| Question | Krótka odpowiedź |
|---|---|
| Jakie jest zadanie? | Zaplanuj i zweryfikuj ograniczone udoskonalenia starszego kodu. |
| Jaki jest Twój wynik? | Analiza ryzyka i dowody na to, że dotychczasowe zachowania zostały zachowane. |
| Czy szerokie przepisanie jest dobrym projektem szkoleniowym? | Zazwyczaj nie. Ukrywa to ćwiczoną umiejętność i utrudnia pokazanie utrwalonego zachowania. |
| Czy quiz dotyczący wzorców refaktoryzacji wystarczy? | Nie. Potwierdza ona wymagania wstępne, ale nie to, czy inżynier może zaplanować i zatwierdzić zmianę. |
| Kto weryfikuje treść? | Kierownik ds. inżynierii i starszy inżynier znający bazę kodu. |
| Czego nie naprawi szkolenie? | Brak narzędzi testowych, ciśnienia zwalniającego, niejasna nazwa właściciela i brak czasu na prace konserwacyjne. |
| Skąd wiesz, że zadziałało? | Nowy, niepublikowany przypadek starszego kodu, oceniony według ustalonych kryteriów, z późniejszym sprawdzeniem rzeczywistej pracy. |
1. Opisz problem z wydajnością
Zacznij od zadania: zaplanuj i zweryfikuj ograniczoną poprawę kodu legacy. „Ograniczona” to ważne słowo. Uczący się wybiera zmianę na tyle małą, aby ją ukończyć, i potrafi określić, co mieści się w zakresie, a co poza nim.
Precyzja w używaniu terminów jest pomocna. Martin Fowler opisuje refaktoryzację jako kontrolowana technika ulepszania projektu istniejącej bazy kodu, składający się z małych, zachowujących zachowanie transformacji. Określenie „zachowujący zachowanie” odróżnia refaktoryzację od przepisywania i to właśnie szkolenie musi uwidocznić. Sama metafora długu technicznego zostało wymyślone przez Warda Cunninghama, a rozważania Fowlera stanowią użyteczne przypomnienie, że zadłużenie można zaciągać rozważnie i rozważnie, więc nie każdy nieuporządkowany moduł jest błędem, który należy naprawić.
Książka Michaela Feathersa o starszym kodzie ma podobne podejście do praktyki. Opis wydawcy mówi, że uczy programistów pisania testów, które zapewniają nie zmieniają aplikacji nieumyślniei przejęcie kontroli nad istniejącym oprogramowaniem bez konieczności jego całkowitego przepisania.
Napisz oświadczenie o wydajności w jednym zdaniu i zleć jego sprawdzenie kierownikowi ds. inżynierii: „Biorąc pod uwagę starszy moduł i zdefiniowany cel, inżynier proponuje ograniczoną zmianę, dodaje testy, które określają bieżące zachowanie, wprowadza zmianę małymi krokami i wykazuje, że zachowanie jest zachowane”.
2. Zdiagnozuj luki w nauce i kontekście
Zanim cokolwiek stworzysz, porównaj wymagane zadanie z tym, co obecnie ćwiczysz i oceń. Trzy pytania zazwyczaj odróżniają lukę w szkoleniu od czegoś innego:
- Czy obecna praktyka wykorzystuje rzeczywiste zadanie? Jeśli szkolenie obejmuje wzorce refaktoryzacji w slajdach, ale nikt nigdy nie zmienia nieprzetestowanego kodu, to nikt nie praktykował zachowań zabezpieczających. Jeśli ocena jest testem wielokrotnego wyboru dotyczącym nieprawidłowości w kodzie, mierzy ona stopień przypomnienia.
- Jakie jest zapotrzebowanie poznawcze? W zrewidowanej taksonomii Blooma ocena, czy zmiana jest bezpieczna, odbywa się na poziomie analizy i oceny, a projektowanie planu i testów na poziomie tworzenia. Dopasowanie działań do tych poziomów opisano w naszym przewodniku. dopasowywanie działań edukacyjnych do taksonomii Blooma.
- Czy coś innego niż umiejętności stoi na przeszkodzie? Sprawdź obsadę kadrową, narzędzia i procedury. Jeśli budowa zajmie godzinę, nikt nie będzie często przeprowadzał testów. Jeśli prace konserwacyjne nie będą nigdy planowane, inżynierowie będą refaktoryzować tylko w tajemnicy. Zgłaszaj przyczyny niezwiązane ze szkoleniem osobom, które mogą je rozwiązać.
3. Zaprojektuj celowe przygotowanie i praktykę
Gdy już wiesz, które luki można wypełnić szkoleniem, przypisz każdemu etapowi odrębne zadanie.
Przygotowanie. Sprawdź wymagania wstępne, przeprowadzając krótką diagnostykę: jak działa Twoja struktura testowa, czym jest test charakteryzacji oraz jak Twój zespół dokonuje przeglądu i scalania. Na tym etapie odpowiednia jest nauka we własnym tempie. Sprawdzenie pamięci potwierdza jedynie spełnienie wymagań wstępnych.
Ćwiczyć. Stosuj systematyczne projekty refaktoryzacji o jasno określonym kształcie. Zacznij od małej, bezpiecznej próbki, a następnie przejdź do rzeczywistej, ale ograniczonej części własnej bazy kodu. Kata Gilded Rose to dobrze znany punkt wyjścia dla pierwszego kroku. Jego plik README, aktualizowany przez Emily Bache, zaleca pisanie testów przed zmianą kodu i przedstawia ćwiczenie jako praktykę małych kroków, częstego uruchamiania testów i stopniowego ulepszania projektu. Rozsądna kolejność dla każdego projektu to: zdefiniuj cel i granice, napisz testy, które uchwycą to, co kod robi dzisiaj, zmieniaj jedną rzecz na raz, uruchamiaj testy po każdym kroku i zapisuj to, czego się nauczyłeś.
Informacje zwrotne. Powiąż informację zwrotną z decyzjami, a nie z wynikiem całkowitym. „Wyodrębniłeś logikę rabatowania, ale testy obejmowały tylko szczęśliwą ścieżkę, więc nie mogłeś zauważyć zmiany w zaokrąglaniu” jest bardziej przydatne niż „3 na 5”.
Wkład instruktora na żywo czy asynchroniczny przegląd? Wprowadzanie danych na żywo przynosi największą wartość, gdy wybór jest niejednoznaczny, na przykład czy przerwać i dodać brakujący test, czy kontynuować. Asynchroniczny przegląd jest wystarczający, gdy uczniowie porównują swój plan i testy z opatrzoną komentarzami wersją ekspercką. Wiele zespołów korzysta z obu metod: najpierw przygotowują się we własnym tempie, a następnie uczestniczą w sesji moderowanej nad trudnymi przypadkami.
4. Omów realistyczny przykład
Ilustrujące. Kierownik ds. inżynierii powinien zweryfikować przypadek i kryteria odpowiedzi przed ich użyciem.
Walizka. Starsza funkcja oblicza wartość zamówienia, uwzględniając rabat, podatek i regułę wysyłki. Nie posiada żadnych testów. Zespół proponuje przebudowę całego modułu rozliczeniowego, aby uczynić go „czystszym”.
Zadanie. Uczeń wyjaśnia, co by zrobił, podaje dowody, które by zebrał, i mówi, jakich dalszych informacji lub wsparcia potrzebuje.
Pierwsza próba. „Podzieliłbym moduł na trzy usługi i przeniósł logikę, a następnie sprawdził liczby w fazie przygotowawczej”. Uczeń wybrał dużą zmianę i późne, ręczne sprawdzenie. Nie ma sposobu, aby stwierdzić, czy stara i nowa wersja zgadzają się co do przypadków skrajnych.
Prześlij opinię i spróbuj ponownie. Recenzent pyta, co funkcja robi dzisiaj dla pustego koszyka, rabatu, który daje wynik ujemny, oraz przypadku zaokrąglenia. Ponowna próba prosi ucznia o zawężenie zakresu do jednego zachowania i wskazanie, jak udowodniłby, że nie uległo ono zmianie.
Silniejsza próba. „Na razie zostawiłbym strukturę modułu w spokoju. Przechwyciłbym to, co funkcja sumy zamówień zwraca dzisiaj dla zestawu danych wejściowych, w tym przypadków skrajnych, jako testy. Następnie wyodrębniłbym obliczenie rabatu do osobnej funkcji, uruchomił testy po tym jednym kroku i zakończył. Zauważyłbym, że reguła wysyłki ma zachowanie, którego nie rozumiem, i zapytałbym kolegę, zanim ją zmienię”. Zauważ, że ta odpowiedź ogranicza zmianę, najpierw chroni zachowanie i wskazuje to, co jest nieznane.
Dlaczego każda odpowiedź jest możliwa do obrony lub niekompletna. Oceniaj każdą z nich według zatwierdzonych kryteriów, a nie preferencji recenzenta. Pierwsza próba może być rozsądnym długoterminowym kierunkiem, ale jako plan jest niekompletna, ponieważ nie niesie ze sobą dowodów na utrwalone zachowania. Silniejsza próba jest niewielka, możliwa do sprawdzenia i uczciwie podchodzi do niepewności.
5. Ocena zdolności i zaplanowanie przeniesienia
Dowodem zdolności jest wydajność w nowym przypadku ze starszym kodem, którego uczeń nie widział. Oceń analizę ryzyka i dowody na to, że zachowanie zostało zachowane. Prosta rubryka używa skali od 0 do 2 dla każdego kryterium:
| Kryterium | Obserwowalne dowody |
|---|---|
| Wykonanie zadania | Planuje i weryfikuje ograniczone udoskonalenia starszego kodu oraz dokumentuje działania i dowody na ich poparcie. |
| Rozumowanie | Wyjaśnia ograniczenia, alternatywy i niepewność, a także sprawdza ryzyka i dowody na to, że zachowanie zostało zachowane. |
| Granice | Stosuje zatwierdzone procedury i prosi o pomoc, gdy informacje lub upoważnienia są niewystarczające. |
Kotwice: 0 oznacza brak lub brak wsparcia, 1 oznacza częściowe pominięcie istotnych elementów, a 2 oznacza kompletne i uzasadnione w odniesieniu do uzgodnionych kryteriów. Zdefiniuj krytyczne błędy osobno, takie jak zmiana zachowania bez zauważonego testu, aby ogólny wynik nie mógł ich ukryć. Ta rubryka jest propozycją, a nie sprawdzonym standardem gotowości: dostosuj ją z kierownikiem ds. inżynierii i przeprowadź pilotaż. Nasz przewodnik po projektowanie interaktywnej praktyki z użyteczną informacją zwrotną pokazuje, jak napisać opinię, która odnosi się do decyzji.
Zaplanuj przeniesienie z rozwagą. Po ćwiczeniu, daj każdemu inżynierowi mały, konkretny fragment do omówienia z recenzentem lub przeprowadź krótką retrospektywę dotyczącą niedawnej zmiany, która coś zepsuła. Sprawdź przeniesienie po odpowiednim zetknięciu się z rzeczywistą pracą, a nie bezpośrednio po warsztatach.
Gdzie interaktywna dostawa pomaga
Formaty interaktywne pomagają w podjęciu decyzji przez każdego przed spotkaniem z grupą. Podczas sesji na żywo prowadzący może pokazać krótki fragment kodu, poprosić każdego inżyniera o podanie pierwszej zmiany, którą wprowadzi i sposobu, w jaki udowodni jej bezpieczeństwo, a następnie ujawnić rozkład przed dyskusją. Ten sam komunikat można uruchomić we własnym tempie, aby się przygotować. AhaSlides wspiera interaktywną naukę i przełączanie się między prezentacją na żywo a we własnym tempie. Jest to narzędzie do prezentacji i nauki, a nie miejsce do uruchamiania lub analizowania kodu, więc samo refaktoryzowanie należy przeprowadzić we własnym środowisku. Sprawdź wszystkie konkretne funkcje tworzenia, przekazywania opinii lub raportowania, na których planujesz polegać, w swoim własnym przepływie pracy. Wskazówki dotyczące wyboru formatów znajdziesz w naszym artykule na temat kiedy stosować naukę adaptacyjną, interaktywną i na żywo.
Zmierz, co się zmieniło
Zdecyduj z wyprzedzeniem, co będzie świadczyć o tym, że inżynierowie potrafią wykonać zadanie. Porównaj jakość analizy ryzyka i dowody na zachowanie zachowania w nieobejrzanym przypadku z sytuacją bazową. Określ, kto jest uwzględniony, jaki jest mianownik i jaki jest czas. Jeśli wyniki się poprawią, sprawdź, co jeszcze zmieniło się w tym samym okresie, na przykład nowe narzędzia testowe, szybsza wersja lub zmiana właściciela, przed uznaniem szkolenia za sukces.
Ograniczenia, które mogą pozostać
- Czas na prace konserwacyjne. Jeśli prace związane z długiem nigdy nie będą zaplanowane, wykwalifikowani inżynierowie nadal nie będą mieli gdzie wykorzystać swoich umiejętności.
- Narzędzia testowe. Bez użytecznych narzędzi testowych lub szybkiej budowy trudno jest utrzymać metodę małych kroków i częste kontrole.
- Relacja ze sprawy. Jeden z przypadków historycznych pokazuje kilka rodzajów ryzyka. Wynik nie opisuje ogólnej oceny inżyniera.
- Ocena, kiedy nie należy przeprowadzać refaktoryzacji. Pewien kod lepiej pozostawić w spokoju, zastąpić lub wycofać, ale decyzja ta wymaga czegoś więcej niż tylko umiejętności.
- Transfer. Wyniki uzyskane w kata nie są takie same, jak wyniki uzyskane w module produkcyjnym pod presją dostarczenia produktu.
Zgłosić je sponsorom z wyprzedzeniem i zaplanować osobne poprawki. Szkolenie poprawia to, co inżynier może zaplanować i udowodnić. Nie tworzy czasu ani narzędzi.
PYTANIA I ODPOWIEDZI
Czym jest projekt szkoleniowy w zakresie refaktoryzacji?
To ustrukturyzowana praktyka w pracy nad starszym kodem, podczas której inżynierowie planują niewielkie zmiany, chronią istniejące zachowanie za pomocą testów, zmieniają projekt małymi krokami i pokazują, że nic nie jest zepsute.
Czy całkowite przepisanie tekstu to dobry sposób na naukę czegoś o długu technicznym?
Zazwyczaj nie. Przepisanie jest obszerne, trudne do walidacji i ukrywa umiejętność, którą chcesz rozwinąć. Ograniczona zmiana z testami, które rejestrują bieżące zachowanie, uwidacznia rozumowanie.
Jak ocenić, czy inżynierowie mogą bezpiecznie dokonać refaktoryzacji?
Podaj nowy przypadek kodu legacy i oceń analizę ryzyka oraz dowody na to, że zachowanie zachowania zostało zachowane zgodnie z ustalonymi kryteriami. Quiz dotyczący wzorców refaktoryzacji potwierdza jedynie spełnienie wymagań wstępnych.
Czy potrzebujesz przykładowej bazy kodu do szkolenia?
Potrzebujesz bezpiecznego miejsca do ćwiczeń. Wiele zespołów zaczyna od publicznego kata, a następnie przechodzi do ograniczonej części własnego kodu. Twój kierownik ds. inżynierii powinien potwierdzić, czy kod jest odpowiedni.
Gdzie zacząć
Wybierz jedną, niewielką, powtarzającą się zmianę w kodzie źródłowym. Napisz deklarację wydajności, poproś kierownika ds. inżynierii o walidację przypadku i testów, które pokażą zachowanie zachowania, a następnie opracuj trzykryterialną rubrykę z skalą od 0 do 2 i listą błędów krytycznych. Przeprowadź pilotaż z małą grupą przed wdrożeniem.
Aby zobaczyć, jak ćwiczenie dotyczące podejmowania decyzji w zakresie refaktoryzacji można przeprowadzić na żywo z udziałem własnego zespołu, a następnie wykorzystać je ponownie w indywidualnym tempie, zapoznaj się z AhaSlides.
