Menu

Refaktoryzacja kodu: co musisz o tym wiedzieć

code refactoring what you need know about it

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Zrozumienie refaktoryzacji kodu: perspektywa testera

Termin „refaktoryzacja” jest używany głównie do wskazania wymaganego oczyszczenia / przeprojektowania kodu.

W tym samouczku zrozumiemy definicję refaktoryzacji, omówimy potrzebę refaktoryzacji kodu i przejrzymy wpływ refaktoryzacji kodu na różnych członków zespołu projektowego. Omówimy również odpowiedź na najważniejsze pytanie - Dlaczego jako tester musisz wiedzieć o refaktoryzacji?

Dodatkowo omówimy również kilka studiów przypadku, aby wyjaśnić tę koncepcję.

Refaktoryzacja kodu

Czego się nauczysz:

Wprowadzenie do refaktoryzacji

Zacznijmy od tego, najpierw zrozumiemy, czym właściwie jest refaktoryzacja.

Refaktoryzacja to w zasadzie praktyka lub proces ulepszania kodu i / lub bazy danych przy jednoczesnym zachowaniu istniejącej funkcjonalności. Chodzi o to, aby przekształcić nieefektywny i zbyt skomplikowany kod w bardziej wydajny, najlepiej prostszy i łatwiejszy kod.

Refaktoryzacja kodu również nabrała tempa wraz z większą liczbą zespołów, stosując podejście Agile Software Development. Zespoły projektowe często mają ograniczony czas na wdrożenie nowych lub rozszerzenie funkcjonalności istniejących funkcji i czystego kodu. Kod, który jest łatwy do zrozumienia i utrzymania, z pewnością przechodzi długą drogę w dotrzymaniu terminu iteracji.

Potrzeba refaktoryzacji kodu

Jeśli zachowujemy oryginalną funkcjonalność aplikacji lub modułu, pojawia się pytanie: Dlaczego w ogóle zawracamy sobie głowę refaktoryzacją? Cóż, istnieje wiele powodów, dla których określony moduł lub fragment kodu może wymagać refaktoryzacji, na przykład:

  1. Kod pachnie
  2. Dług techniczny
  3. Podejście do zwinnego tworzenia oprogramowania itp.

Omówimy szczegółowo te punkty w kolejnych sekcjach.

# 1) Kod pachnie:

Wszyscy możemy zrozumieć, że kiedy jedzenie zaczyna pachnieć, oznacza to, że najprawdopodobniej się zepsuje - dotyczy to również kodu! Zapachy kodu wskazują, że w kodzie może istnieć dużo poważny problem.

Oto kilka typowych zapachów kodu:

  • Obecność zbędnego lub identycznego kodu.
  • Zadeklarowana zmienna, która nie jest używana w pozostałej części kodu.
  • Zbyt skomplikowany projekt kodu.
  • Klasa kodu, która robi za mało i nie uzasadnia istnienia zdefiniowanej klasy. Takie klasy są znane jako lazy class lub freeloader.
  • Istnienie zbyt wielu warunków i pętli, które mogą zostać rozbite i uproszczone.
  • Kod zbudowany w taki sposób, że zmiana w jednej jego części wymaga implementacji zmiany również w innych miejscach.

Z upływem czasu zapachy kodów stają się bardziej widoczne. Wraz z rozwojem aplikacji lub systemu te zapachy kodu zaczynają wpływać na rozwój kodu, konserwację, a nawet wydajność systemu w ekstremalnych scenariuszach.

# 2) Dług techniczny:

Tworząc oprogramowanie, przy ograniczonym czasie i dostępnych zasobach, często możemy iść na skróty, aby osiągnąć pożądane rezultaty.

Rozważ funkcję, którą należy dodać do istniejącego modułu. Po dyskusji zespół zawęził 2 podejścia do dodania tej funkcji. Podejście A, które wymaga 2 sprintów, będzie zatwierdzonym podejściem długoterminowym. Podejście B zajmuje tylko 5 dni, to chaotyczny, trwale zakodowany hack, który ma na celu tylko krótkoterminową obsługę modułu.

Jeśli zespół jest pod presją, aby dostarczyć tę funkcję w ograniczonym czasie, może zgodzić się na teraz zastosować Podejście B i dodać Podejście A do listy zadań na przyszłość. Robiąc to, ten zespół właśnie stworzył dla siebie dług techniczny.

Mówiąc prościej, dług techniczny związany z rozwojem oprogramowania odnosi się do dodatkowej pracy lub kosztów ogólnych wymaganych do wprowadzenia odpowiednich poprawek lub wykonania czynności we „właściwy sposób”.

Starsze systemy mają tendencję do zaciągania ogromnych długów technicznych z czasem, co z kolei może spowodować, że aplikacja będzie podatna na awarie oraz trudna w obsłudze i utrzymaniu.

Czytaj więcej=> Co to jest dział techniczny

# 3) Zgodnie ze zwinnym podejściem do tworzenia oprogramowania:

Zwinne podejście do tworzenia oprogramowania jest zwolennikiem stopniowego rozwoju. Bez czystego, dobrze zorganizowanego i łatwego w utrzymaniu kodu zespoły nie byłyby w stanie rozszerzać istniejącego kodu w każdej iteracji. Jeśli kod zostanie zmieniony bez odpowiedniej refaktoryzacji, może to przyczynić się do zapachów kodu lub długu technicznego.

Ten związek jest przedstawiony na poniższym diagramie

Podejście do zwinnego tworzenia oprogramowania

Zalecane Przeczytaj => Najlepsze narzędzia do analizy kodu

Dlaczego dział kontroli jakości musi wiedzieć o refaktoryzacji?

Cokolwiek omówiliśmy do tej pory w tym samouczku, wydaje się być związane z kodowaniem i wygląda na rodzaj rzeczy, o które powinien się martwić programista.

Dlaczego więc omawiamy tę niepowiązaną koncepcję w społeczności pomocy do testowania oprogramowania? Kontynuuj czytanie pozostałej części tego samouczka, aby znaleźć odpowiedź na to pytanie.

1) Dla testerów / programistów jednostkowych

Podczas refaktoryzacji kodu podczas wstawiania nowego kodu aktualizowane są stare klasy, dodawane są nowe klasy, a istniejące testy jednostkowe mogą teraz zakończyć się niepowodzeniem. Ponadto w przypadku starszych systemów mogą w ogóle nie być zaimplementowane testy jednostkowe. W większości przypadków nowe testy jednostkowe będą musiały zostać utworzone i skonfigurowane od podstaw.

# 2) Dla testerów

Kiedy funkcja jest refaktoryzowana (biorąc pod uwagę, że nie dodajemy żadnej nowej funkcjonalności), rozumie się, że po wprowadzeniu wymaganych zmian większość funkcjonalności dla użytkownika końcowego powinna pozostać taka sama.

  • Jako tester, refaktoryzacja kodu z grubsza przekłada się na = testowanie dogłębne + testowanie regresji. Dogłębne testy muszą obejmować wszystkie istniejące przepływy użytkowników, aby upewnić się, że wszystkie funkcje działają jak wcześniej. Testowanie regresji całej aplikacji (lub obszarów, na które ma to wpływ) jest wymagane, aby aktualizacja modułu nie spowodowała niezamierzonego zakłócenia funkcjonalności innych modułów.
  • Testy akceptacyjne użytkowników będą ważne i testy te muszą przejść, zanim kompilacja zostanie uznana za gotową do wydania.
  • Ponadto wszelkie inne wymagane testy, takie jak testy obciążenia, test bezpieczeństwa itp. należałoby również wdrożyć zgodnie z wymaganiami.

# 3) Inżynierowie ds. Testów automatyzacji

Refaktoryzacja kodu może spowodować awarię funkcjonalnych i niefunkcjonalnych skryptów automatyzacji.

Może to nastąpić z następujących powodów:

  • Jeśli obiekty strony zmienią się w ramach procesu refaktoryzacji i jeśli skrypty automatyzacji Selenium opierają się na obiektach strony, skrypty nie powiodą się i będą musiały zostać zaktualizowane.
  • Gdyby były drobne zmiany, przekierowuje te, które zostały dodane lub usunięte podczas refaktoryzacji, a istniejące skrypty automatyzacji zawiodą i będą musiały zostać zaktualizowane

Zaleca się, aby testy automatyzacji funkcjonalnej były konfigurowane tylko wtedy, gdy funkcja jest stabilna, w przeciwnym razie spowoduje to wiele przeróbek w miarę rozwoju funkcji.

Będąc programistą testów automatyzacyjnych, inżynierowie testów automatycznych muszą również myśleć jak programista i starać się tworzyć czysty i łatwy w utrzymaniu kod. Większość IDE, takich jak IntelliJ IDEA, Eclipse itp., Zawiera wbudowane menu refaktoryzacji z powszechnie używanymi metodami refaktoryzacji dla łatwego odniesienia.

Poniżej znajduje się zrzut ekranu menu refaktoryzacji w IntelliJ IDEA (Community Edition).

najlepszy downloader piosenek mp3 dla Androida

menu refaktoryzacji

# 4) W przypadku potencjalnych klientów / potencjalnych klientów do kontroli jakości

  • Testy / leady QA mogą być wymagane do współpracy z resztą zespołu, w tym programistami, analitykami produktu, a może nawet interesariuszami, aby zapewnić, że planowanie testów dla takich projektów jest wykonywane ostrożnie.
  • Ważne jest, aby zrozumieć istniejącą funkcjonalność. Na podstawie istniejącej funkcjonalności należy udokumentować przypadki biznesowe, przepływy użytkowników i testy akceptacyjne użytkowników. Kiedy testowany jest kod refaktoryzowany, wszystkie te scenariusze muszą zostać zweryfikowane, wraz z testami regresyjnymi obszarów, których dotyczy problem.
  • Bądź proaktywny podczas planowania podejścia do testów i plany testów . Jeśli przewidujesz zapotrzebowanie na wiele środowisk testowych lub nowe narzędzia testowe, wyślij zamówienie wcześniej, aby uniknąć opóźnień po rozpoczęciu fazy testowania.
  • Nie wahaj się zaangażować członków zespołu spoza zespołu projektowego lub użytkowników końcowych do udziału w testowaniu.

Studium przypadku

Omówimy teraz kilka przykładów z życia wziętych, nad którymi miałem okazję pracować bezpośrednio lub pośrednio.

Studium przypadku nr 1

Zadanie: Przebuduj moduł, aby zastąpić wartości zakodowane na stałe zmiennymi i dodać komentarze do nowego narzędzia do automatycznego generowania dokumentacji technicznej.

Wyzwania :Żadnych większych wyzwań. Moduł był nowy, miał udokumentowane wymagania funkcjonalne i wymagania akceptacji użytkownika, przepływy użytkowników i przypadki testowe. Testy jednostkowe zostały skonfigurowane podczas samego pierwszego uruchomienia.

Podejście testowe :Wykonano przypadki testowe dla refaktoryzowanego modułu i stosunkowo znanych obszarów, na które ma to wpływ. Wszelkie wady zostały zgłoszone i usunięte przed wydaniem.

Studium przypadku nr 2

Zadanie :Przebuduj istniejącą procedurę składowaną, aby ułatwić skalowanie aplikacji.

Procedura składowana w tym scenariuszu była starszą procedurą składowaną, która została zaprojektowana kilka lat temu, mając na uwadze wymaganie, aby aplikacja używała procedury składowanej jako aplikacji wewnętrznej z mniej niż 10 sesjami współbieżnymi.

Teraz firma chciała sprzedawać tę aplikację jako oprogramowanie jako usługę (SaaS), z oczekiwaną początkowo liczbą 300 jednoczesnych sesji.

Zespół przeprowadził wstępne testy obciążenia i stwierdził, że system psuje się przy obciążeniu 25 jednoczesnych sesji. Zespół przeanalizował kod i zalecił refaktoryzację jednej istniejącej podstawowej procedury składowanej, która umożliwiłaby skalowanie aplikacji i obsługę do 500 jednoczesnych sesji bez przerywania pracy.

Niektóre problemy zidentyfikowane w tej procedurze składowanej to wiele podzapytań w ramach jednego zapytania, ciężkie sprzężenia z widokami zamiast tabel, użycie funkcji select * zamiast wybierania określonej kolumny itp. Z powodu tych problemów z kodowaniem aplikacja pobierała więcej danych. było naprawdę konieczne, powodując w ten sposób spowolnienie aplikacji i jej awarię.

Wyzwania:

1) Kierownik projektu / Analityk produktu

  • Gromadzenie wymagań - Ponieważ ta procedura składowana była starszym kodem, nie było udokumentowanych wymagań dla niej podczas pierwszego projektowania modułu. Również w przypadku iteracji wykonanych w ciągu ostatnich kilku lat nie było dziennika zmian wskazującego reguły biznesowe i logikę dodaną lub usuniętą z modułu.
  • Harmonogram projektu - Ponieważ wymagania nie zostały jasno zdefiniowane, a zależności w kodzie nie zostały jeszcze w pełni zidentyfikowane, trudno było przekazać wstępny harmonogram.

# 2) Dla programistów

  • Brak jasnych wymagań i reguł biznesowych.
  • Czyszczenie kodu bez utraty jego funkcjonalności.
  • Nieznane obszary i / lub zależności kodu.
  • Nie można podać konkretnych szacunków dotyczących czasu rozwoju.
  • Trzeba stworzyć nowe testy jednostkowe.

# 3) Dla testerów

  • Brak jasnych wymagań i reguł biznesowych wpływa na planowanie testów.
  • Planowanie testów wpływu na nieznane obszary objęte wpływem, szczególnie w przypadku testów regresyjnych.
  • Nie można podać konkretnych szacunków dotyczących testów.

# 4) Interesariusze

  • Brak jasno udokumentowanych wymagań i / lub przepływów użytkowników + krótkie terminy = większe ryzyko niepowodzenia.

Podejście zastosowane przez zespół do ograniczania ryzyka i radzenia sobie z wyzwaniami :

(i) Zespół przyjął podejście oparte na współpracy w celu zebrania wymagań : Kierownik projektu / analityk produktu i testerzy ściśle współpracowali z wewnętrznymi użytkownikami końcowymi w celu zrozumienia i udokumentowania głównych funkcji i przepływu użytkowników.

Programiści przejrzeli również kod i dodali odpowiednie informacje do dokumentu wymagań. Zrobiono to przed dniem rozpoczęcia sprintu.

(ii) Alternatywne środowisko testowe zostało utworzone w celu przetestowania wprowadzanej zmiany : Nazwijmy te środowiska jako Gamma i Phi. Gamma miałby stary kod, a Phi miałby zawsze wdrażaną najnowszą refaktoryzowaną procedurę składowaną.

Mając równolegle 2 środowiska testowe, prawie odtwarzając je przed i po podejściu, zespół mógł przeprowadzić bardziej dogłębne i eksploracyjne testy poprzez porównanie zachowania w tych 2 środowiskach testowych, dzięki czemu byli w stanie zidentyfikować prawdopodobne błędy.

Zespół przedstawił wymagania dotyczące alternatywnego środowiska testowego, które zostało udostępnione przed datą rozpoczęcia sprintu.

(iii) Użytkownicy końcowi i interesariusze zaangażowani we wczesne testy : Wszelkie oczywiste problemy zostały wykryte i zgłoszone wcześnie, dając zespołowi więcej czasu na wdrożenie i przetestowanie wymaganej poprawki.

(iv) Definiowanie kryteriów wyjścia i przestrzeganie ich: Kryteria zakończenia zostały zdefiniowane na początkowych etapach planowania - przetestowano 80% przepływów użytkowników, żaden krytyczny błąd nie został rozwiązany, demonstracja i wypisanie się od interesariuszy przed wydaniem.

(v) Ustalenie wstępnej daty premiery: Ustalenie daty premiery i zmotywowanie zespołu do pracy nad wspólnym punktem końcowym. W oparciu o zakres projektu zespół zalecił, aby zamiast zwykłego dwutygodniowego sprintu zastosować 3-tygodniowy sprint, aby zapewnić zespołowi wystarczająco dużo czasu na wykonanie projektu.

Wniosek

Podsumowując, refaktoryzacja kodu to proces mający na celu oczyszczenie / uproszczenie projektu modułu bez zmiany jego funkcjonalności. Proces refaktoryzacji może być prosty, jak dodawanie komentarzy, dodawanie poprawnych wcięć, usuwanie zmiennej statycznej itp. Lub może być skomplikowany w przypadku złożonych starszych systemów.

Określony moduł lub fragment kodu może wymagać refaktoryzacji z powodu zapachów kodu, długu technicznego lub zgodnie z podejściem elastycznego tworzenia oprogramowania.

Dla testerów refaktoryzacja kodu z grubsza przekłada się na = testowanie szczegółowe + testowanie regresji.

Wymagane są dogłębne testy, aby przetestować wszystkie istniejące przepływy użytkowników, aby upewnić się, że wszystkie funkcje działają jak wcześniej. Testowanie regresyjne całej aplikacji (lub obszarów, na które ma to wpływ) jest wymagane, aby zapewnić, że aktualizacja modułu nie spowoduje niezamierzonego zakłócenia funkcjonalności innych modułów.

Test Leads / QA Leads mogą być wymagane do współpracy z resztą zespołu, w tym programistami, analitykiem produktu, zwłaszcza w przypadku starszych projektów. Bądź proaktywny podczas planowania podejścia do testów i planów testów. Jeśli przewidujesz zapotrzebowanie na wiele środowisk testowych lub nowe narzędzia testowe, wyślij zamówienie odpowiednio wcześnie, aby uniknąć opóźnień po rozpoczęciu fazy testowania.

O autorze: Ten samouczek informacyjny został napisany przez Nehę B. Obecnie pracuje jako kierownik ds. Zapewnienia jakości i specjalizuje się w kierowaniu i zarządzaniu zespołami kontroli jakości na miejscu i poza nim.

Czy pracowałeś nad trudnym projektem, który obejmował refaktoryzację kodu lub modułu / aplikacji? Jeśli tak, podziel się swoimi doświadczeniami w sekcji komentarzy, aby inni testerzy mogli się od nich uczyć.

rekomendowane lektury

^