Refaktoring – co to jest i kiedy go porzebujesz?

Pytanie 1. Co to jest refaktoring?

Refaktoring to proces restrukturyzacji istniejącego kodu komputerowego - zmiana faktoringu - bez zmiany jego zachowania zewnętrznego. Refaktoryzacja poprawia niefunkcjonalne atrybuty oprogramowania. Zalety obejmują lepszą czytelność kodu i zmniejszoną złożoność, mogą one poprawić konserwowalność kodu źródłowego i stworzyć bardziej wyrazistą architekturę wewnętrzną lub model obiektowy w celu poprawy rozszerzalności.              

Tym razem postaramy się pominąć „nudne” kwestie techniczne i skupić się na tym, czego naprawdę potrzebują firmy - sprawnie działających aplikacji i oprogramowania. Tworzenie aplikacji mobilnych, aplikacji webowych i różnego rodzaju oprogramowania opiera się na kodzie, który bywa, że się starzeje czy wymaga poprawy z powodu błędów czy zmiany koncepcji.

W bardziej przyziemnym języku refaktoryzacja to proces reorganizacji bazy kodu bez wprowadzania nowych funkcji.

Czyli co? Zasadniczo chcesz coś zrobić z kodem (którego nie widzisz) i spędzić czas na programowaniu BEZ dodawania nowych funkcji? Żartujesz, prawda?

Odpowiemy na to pytanie nieco później.

Pytanie 2. Skąd mam wiedzieć czy moja aplikacja wymaga refaktoryzacji?

Istnieją trzy główne powody, aby przeprowadzić refaktoring:

1. Architektura kodu jest słaba. Dzieje się tak, gdy aplikacja jest dostarczana tak szybko jak to możliwe, a deweloperzy i właściciel produktu nie dbają o integralność i łatwość konserwacji rozwiązania. Sytuacja może się jeszcze pogorszyć, jeśli zakres projektu znacznie się zmienił lub było kilkudziesięciu freelancerów, którzy pracowali nad rozwiązaniem w różnym czasie (bez konwencji, stylu kodu itp.) 
2. Projekt nie potwierdził, że koncepcja była słuszna. Nie jest tajemnicą, że niektóre projekty odnoszą sukcesy, a niektóre kończą się niepowodzeniem. Właściciele inteligentnych produktów muszą upewnić się, że kluczowe funkcje działają zgodnie z przeznaczeniem i mogą być zademonstrowane inwestorom i interesariuszom. Lub, podobnie jak firmy produktowe, weryfikują swoje pomysły w wąskich grupach fokusowych. W każdym przypadku przydzielają ograniczone zasoby, aby sprawdzić, czy pomysł lub podejście rzeczywiście działa w prawdziwym świecie. Jak tylko pojawi się odpowiedź „tak - to działa”, powinieneś zaplanować budżet na następujące zadania i (jest to ważny element) faktycznie zaplanować lub dostosować architekturę rozwiązania. W przeciwnym razie możesz zbudować wieżowiec na ruchomych piaskach. 
3. Stack technologii jest przestarzały. To też się zdarza. Technologie ewoluują szybko, firmy potrzebują rozwiązań wieloplatformowych, adaptacji mobilnej itp. Wejdź na stronę internetową z 1999 roku i spróbuj dodać do niej fantazyjną interaktywność ReactJS. Możesz spróbować sprawić, by działało, ale w zasadzie oczekiwany wynik nie może być uzasadniony ilością czasu.

Kiedy taka wiadomość nadchodzi od firmy deweloperskiej, to jest to powód do łez, prawda?

Cóż... tak i nie.

Możesz zignorować informację, pominąć audyt kodu innej firmy i po prostu przejść do obecnego podejścia.

Oto lista możliwych problemów z aplikacją, które wymagają refaktoryzacji kodu:

1. Aplikacja posiada błędy

   . Z biegiem czasu niektóre błędy są rozwiązywane, aby zastąpić je nowymi. Dlaczego? Ponieważ programiści naprawiają problemy, ale dopiero wtedy staje się widoczne, że zepsuli coś innego. Im większa aplikacja, tym więcej linii kodu, tym więcej skrzyżowań, tym więcej niekonwencjonalnych rozwiązań i... tym gorsza jest zwykle sytuacja. 

2. Aplikacja działa zbyt wolno

   . Wprowadzając nową funkcjonalność nieuchronnie dodajesz kod. Gdy dodajesz więcej danych do DB, zwiększasz rozmiar. Tak więc na wczesnych etapach problemy z wydajnością po stronie serwera lub klienta mogą nie być widoczne. Ale z biegiem czasu mogą stać się dość oczywiste. 

3. Konieczny rozwój aplikacji

   . Nawet w przypadku prostych funkcji. Jest to związane z poprzednim punktem. Aby dostarczyć stabilny produkt, programista musi rozwiązać problemy poza swoim zakresem, w zasadzie dokonuje refaktoryzacji, jednocześnie zapewniając tę ​​funkcję. To działa, ale brakuje systematycznego podejścia. I nie jest to dla Ciebie przejrzyste z poziomu osoby płacącej rachunki, prawda? 

4. Nowe funkcje i komponenty w aplikacji

   . Ponownie, odnosząc się do obu powyższych. Wprowadzenie nowego komponentu lub funkcji może po prostu nie być warte wysiłku. Wyobraź sobie, że otrzymujesz oszacowanie, które mówi, że stworzenie prostego menu rozwijanego zajmie dwa pełne dni. Firma programistyczna zazwyczaj mówi „nie potrzebujesz” lub coś w tym rodzaju. 

Pytanie 3. Jakie są korzyści z refaktoryzacji kodu?

Korzyści z właściwego refaktoringu są bezpośrednio związane z problemami, które zamierzamy rozwiązać:

• Łatwiejsza rozbudowa systemu
• Lepsza współpraca programistów
• Mniej czasu na dyskusje, więcej czasu na dobre rozwiązania
• Zaoszczędzone pieniądze
• Łatwiejsze wdrażanie zmian
• Mniej błędów
• Mniej Q&A
• Lepsza wydajność aplikacji po stronie klienta 
• Szczęśliwi klienci
• Lepsza wydajność po stronie serwera
• Tańszy plan AWS
• Mniej pieniędzy wydanych na wsparcie i rozwój w przyszłości

Lista jest długa. Zasadniczo będziesz w stanie rozwiązać większość, jeśli nie wszystkie, wyżej wymienione problemy.

Pytanie 4. Ile kosztuje refaaktoring kodu?

Krótka odpowiedź - to zależy.

Dłuższa wersja brzmi - od 100 godzin do 2000+.

Małe projekty mogą potrwać 50–150 godzin, aby zaktualizować stack technologii.

Większe projekty ze zmianami w backend i frontend mogą z łatwością zająć 500h+.

Może to też zająć 10–15 godzin, tylko dlatego, że musimy pozbyć się nieoptymalnych rozwiązań i iść naprzód, ewoluować i gromadzić fundusze.

Ważne jest, aby właściwie informować programistów o swoich planach - bliskich i odległych. To najważniejsze od samego początku. Czasami (dość często) sensowne jest łączenie refaktoryzacji i wdrażania nowych funkcji, gdy masz pewność, że starsza funkcjonalność zostanie wkrótce zmieniona.

W razie wątpliwości możesz zamówić audyt kodu innej, sprawdzonej firmy. Nie są one tanie, ale mogą być całkowicie uzasadnione, gdy mówimy o zakresach ponad 1000 godzin.

Pytanie 5. Jak uniknąć refaktoryzacji? 

Zasada 1. Znajdź odpowiednich ludzi. Firma deweloperska powinna być profesjonalna, przejrzysta i mieć dobrą reputację. 

Zasada 2. Wyraź swoje życzenia. Zrozumienie marzenia w pełnej krasie i oddanie go SRS może być trudne. Przeczytaj, jak działa SCRUM i co robi właściciel produktu. 

Zasada 3. Sprecyzuj swoją grupę docelową, interesariuszy, plany na przyszłość. Im dokładniejszy jest obraz, tym mniej miejsca na fałszywe założenia i tym większa szansa na spełnienie oczekiwań. 

Zasada 4. Poinformuj firmę deweloperską, kiedy nastąpi znacząca zmiana ról w projekcie, wysokie prawdopodobieństwo zmiany podejścia lub anulowania zakresu. Pamiętaj, że prowadzimy projekt i powinien on idealnie pasować do produktu - jesteś osobą, która najlepiej o tym wie. 

Zasada 5. Nie odkładaj zapewnienia jakości na „kiedy nadejdzie czas”. Skumulowane problemy są trudniejsze do naprawienia. Ponadto ich rozwiązanie zajmie trochę czasu (i pieniędzy), a Ty w zasadzie nie będziesz otrzymywać nowych funkcji w tym momencie. W końcu płacisz za to, co już uważałeś za rozwiązane. Frustrujesz się, a odbiorcy mają luki w kolejnych wydaniach/wersjach.

Zasada 6. Planuj z wyprzedzeniem. W pewnym momencie będziesz potrzebować adaptacji mobilnej (bardzo prawdopodobne) lub kilku aplikacji i ról użytkowników. Spróbuj wyobrazić sobie, jak to ostatecznie wygląda, a następnie przenieś swoją wizję do właściwych ludzi. Umożliwia to skuteczne planowanie architektury i wybór odpowiedniego stacka technologicznego. 

Ok, masz już komplet informacji. Konieczna jest refaktoryzacja.

Zła wiadomość: Potrzebna nowa inwestycja, czasem (często) nieplanowana. 

Dobra wiadomość: Produkt będzie lepszy na wielu płaszczyznach. Mam nadzieję, że teraz to zobaczysz. 

Porada - nie traktuj tego jako wydatku. To mądra inwestycja. Jeśli zdecydujesz inaczej, możesz wydać dwa razy więcej później lub gorzej - utknąć w ślepym zaułku. Skontaktuj się z nami, aby poznać szczegóły dotyczące refaktoringu.