Refactoring

Z Encyklopedia Zarządzania
Refactoring
Polecane artykuły

Refactoring polega na przeglądaniu i poprawianiu napisanego już kodu programu w celu jego usprawnienia. Wprowadzone zmiany nie mają wpływu na działanie programu. Jego zadaniem jest porządkowanie kodu minimalizując przy tym ryzyko powstania błędów. Według Martin'a Fowler'a podczas tworzenia oprogramowania w pierwszej kolejności projektuje się, następnie koduje, a z czasem kod poddawany jest modyfikacjom, które stopniowo zacierają spójność systemu. Podkreśla on że refaktoryzacja powoduję coś odwrotnego. "Dzięki niej można zły, chaotyczny projekt przekształcić w dobrze zaprojektowany kod. Przemieszcza się jednej klasy do drugiej, wydziela się kod z jakiejś metody, żeby przerobić go na nową metodę, przesuwa się fragment kodu w górę lub w dół hierarchii dziedziczenia".[1] Można zaobserwować iż skutki zmian zmieniają i udoskonalają projekt. Działania jakie podejmujemy korzystając z refaktoringu to modyfikacja systemów lub kodu oraz szukanie nowych wzorców do usprawnienia. Gwarantują one ograniczenie redundancji to znaczy istnienia procedur o identycznej funkcjonalności[2]

TL;DR

Refaktoryzacja to proces przeglądania i poprawiania istniejącego kodu programu w celu jego usprawnienia. Zmiany wprowadzane podczas refaktoryzacji nie mają wpływu na działanie programu, a jej celem jest uporządkowanie kodu i minimalizacja ryzyka powstania błędów. Refaktoryzacja ma wiele korzyści, takich jak usprawnienie projektu, zwiększenie przejrzystości oprogramowania, szybsze wyszukiwanie błędów i szybsze programowanie. Może być przeprowadzana podczas dodawania nowych funkcji, naprawiania błędów lub przeglądania kodu. Istnieją również pewne problemy i sytuacje, w których refaktoryzacja nie jest możliwa lub nie jest zalecana. Refaktoryzacja może być również stosowana w kontekście ekonomicznym, gdzie jest to proces uzyskiwania wierzytelności handlowej.

Cele refaktoryzacji

  • usprawnienie projektu - celem refaktoryzacji jest ochrona struktury oprogramowania przed rozkładem [3]. Podczas zmiany kodu przez programistów jest on narażony na utratę struktury co powoduje, że zrozumienie struktury oprogramowania jest zdecydowanie cięższe. Dzięki refaktoryzacji możemy uporządkować taki program co stworzy go bardziej przejrzystym oraz łatwiejszym do zrozumienia. Systematyczna refaktoryzacja pozwala na utrzymanie kodu w dobrej kondycji.
  • przejrzystość oprogramowania - każda osoba może zrozumieć założenie i proces myślowy autora
  • szybsze wyszukiwanie błędów - podczas refaktoryzacji można lepiej zrozumieć program i jego działanie a przez to można szybciej znaleźć błędy i usprawnić go
  • szybsze programowanie - do spowalniania pracy przyczynia się nieodpowiedni projekt. Zamiast dodawać coraz to nowsze funkcje, marnuje się czas na lustrowanie i szukanie oraz naprawę istniejących błędów. Zmiany absorbują znacznie więcej czasu w momencie kiedy staram się zgłębić jak działa system. Dodawanie nowych funkcji obliguje coraz to więcej kodowania dlatego, że należy poprawić poprawkę ówczesnej poprawki aby powrócić do bazowej wersji kodu. Wynika z tego, że dobry projekt jest podstawą kiedy chcemy w szybki i prosty sposób programować. W tym właśnie pomaga refaktoryzacja - nie zezwala do stopniowego rozkładu struktury programu[4]

Czas na refaktoryzację

Wyróżnia się kilka określonych terminów na proces:

  • Podczas dodawania funkcji - pomaga to zrozumieć kod, który chcemy zmienić, należy refaktoryzować kiedy struktura programu przeszkadza dołączyć nową funkcję dzięki temu ułatwia to i staje bardziej wydajną późniejszą pracę.
  • Podczas reperowania błędu - kod staje się przejrzysty, jeśli korzysta się z refaktoryzacji to oznacza, że kod nie był wystarczająco czytelny, żeby wcześniej dostrzec w nim błędy.
  • Podczas lustrowania kodu - refaktoryzacja jest najbardziej skuteczna podczas regularnego przeglądania kodu. Dzięki systematycznemu przeglądaniu kodu szybciej rozprzestrzenia się wiedza w całym zespole programistów ponieważ starsi pracownicy udzielają ją tym mniej zaawansowanym. W ten sposób większa ilość programistów rozumie rozliczane aspekty [5]. Dzięki przeglądom większa liczba pracowników może zaaplikować nowymi, ciekawymi pomysłami. Refaktoryzacja daje bardziej klarowne wyniki. Najważniejszym podczas lustrowania kodu jest ograniczona liczba osób wykonujących to zadanie.

Problemy podczas procesu refaktoryzacji

Mogą występować:

  1. w bazach danych - są trudne w modyfikacji, trudności objawiają się także w migracji danych
  2. podczas zmiany interfejsu - refaktoryzacja w znacznym stopniu wpływa na zmiany interfejsu[6]

Kiedy nie możemy korzystać z refaktoryzacji

  1. Jeśli istniejący kod jest zły na tyle, że pomimo możliwości zastosowania procesu refaktoryzacji, najprościej będzie napisać go od nowa. Taka sytuacja powinna mieć miejsce, kiedy program nie działa. Błędy mogą być odkryte podczas procesu testowania. Przed zastosowaniem refaktoryzacji program powinien działać bez komplikacji.
  2. Jeśli zbliża się czas złożenia projektu. Ward Cunningham porównuje nieskończoną refaktoryzację do długu - "Większość firm potrzebuje pożyczek, by móc wydajnie działać. Ale długi to także odsetki, czyli dodatkowe koszty pielęgnacji i rozbudowy spowodowane zbyt skomplikowanym kodem. Do pewnego momentu można sobie radzić z odsetkami, ale jeśli staną się zbyt wysokie, przygniotą nas. Dlatego ważne jest radzenie sobie z długiem przez spłacanie go ratami dzięki refaktoryzacji" [7].

Refaktoryzacja w ujęciu ekonomicznym

Jest to uzyskanie wierzytelności handlowej przez osobę, która poprzednio sama ją kupiła. Ma to miejsce na podstawie umowy factoringu. Faktor składa ofertę wierzytelności do skupu. Refaktoring staje się opłacalny kiedy cena sprzedaży jest wyższa niż zakupu. Wykorzystanie refaktoringu pozwala faktorowi:

  • zwiększyć ilość podmiotów współpracujących z faktorem
  • zwiększyć zaangażowanie faktoringowe
  • powiększyć zasięg działania
  • wzmocnić swoją pozycje na rynku.

Bazowym czynnikiem przeprowadzenia refaktoringu jest prawidłowo przygotowana umowa. Powinna ona określać bezpośrednie i zrozumiale warunki współpracy oraz rozliczenia wprowadzone między refaktorantem a faktorem[8]

Przypisy

  1. ↑ M. Fowler 2018, Refactoring
  2. ↑ M. Fowler 2018, Refactoring
  3. ↑ M. Fowler 1996, s. 55
  4. ↑ M. Fowler 1996, s. 55-56
  5. ↑ M. Fowler 1996, s. 59
  6. ↑ M. Fowler 1996, s. 63
  7. ↑ M. Fowler 1996, s. 59
  8. ↑ A. Dmowski 2008, s. 340

Bibliografia

  • Czajkowski K. i in. (2004).From Open Grid Services Infrastructure to WSResource, "Refactoring & Evolution" nr 3/05
  • Dmowski A., Sarnowski S., Prokopowicz D. (2008).Finanse i bankowość. Teoria i praktyka Wydawnictwo Difin, Warszawa
  • Fowler M. (2018).Refactoring, "Refactoring"
  • Fowler M. i in. (1996).Refactoring. Improving the Design of Exiting Code, The Addison-Wesley, Boston, USA
  • Kerievsky J. (2004), Refaktoryzacja do wzorców projektowych, Wydawnictwo Helion, Gliwice
  • Kruczkiewicz Z. (2011).Tworzenie systemów informatycznych, "Inżynieria oprogramowania" nr 1


Autor: Wioletta Maciaszek


Źródło: „https://mfiles.pl/pl/index.php?title=Refactoring&oldid=165106”