Cześć, dzień dobry. Witam was w podcastzie IT i Biznes. Nazywam się Grzegorz Tabor i na co dzień prowadzę trzy firmy, w tym firmę programistyczną, agencję doradczo-rekrutacyjną i SaaS do monitoringu cen konkurencji dla e-commerce.Podcast IT i Biznes kieruje do właścicieli firm oraz menadżerów, którzy na co dzień współpracują w swoich firmach często i dużo z szeroko pojętym IT i chcieliby realizować owe projekty IT bardziej świadomie i skuteczniej. Odcinek 23. Refactoring kodu.

Dlaczego czasem warto modernizować zamiast budować od nowa? Cześć, witam was w kolejnym odcinku podcastu, w którym jak zwykle rozkładamy na czynniki pierwsze, to co ważne, ale często pomijane. No bo kto ma na to czas, prawda? Dziś bierzemy na warsztat refactoring kodu. Brzmi jak nudny, techniczny bełkot? Może tak, ale dajcie mi chwilę.

Zobaczycie, że to temat, który może uchronić wasze systemy przed totalnym chaosem. Co to w ogóle jest ten refactoring kodu? I czemu to takie ważne, żeby o tym mówić? Tego dowiecie się z dzisiejszego odcinka, zatem nie przedłużając serdecznie zapraszam. Cześć, dzień dobry.

Dziś bierzemy na warsztat temat refactoringu kodu. Brzmi jak nudny, techniczny bełkot? Może tak, ale dajcie mi chwilę. Zobaczycie, że to temat, który może uchronić wasze systemy przed totalnym chaosem.

Kto pracuje z programistami, ten wie, że prędzej czy później padnie magiczne sformułowanie. No trzeba to zrefaktoryzować. No i co to w ogóle jest ten refactoring kodu? I czemu to takie ważne, żeby o tym mówić? Mówiąc w skrócie, refactoring to proces restrukturyzacji istniejącego kodu bez zmiany jego zewnętrznego zachowania.

I teraz chodzi tutaj o to, żeby w ramach tej definicji, aby tak modyfikować kod, czyli go uporządkowywać, sprawiać, aby był jeszcze czystszy, jeszcze bardziej w cudzysłowie pachnący, albo przynajmniej, żeby nie pachniał brzydko, jak to się mówi w IT, bez zmiany jego zewnętrznego zachowania, czyli żeby on po prostu, dana funkcjonalność, którą ten kod reprezentuje, działała dokładnie tak samo. Teraz ja nie do końca się zgadzam z tą definicją, bo jak tu połączyć miłość programistów do czystego kodu, z którą notabene sam się utożsamiam, bo widzę w tym realne korzyści biznesowe, właśnie z też realnym podejściem do tego tematu z poziomu biznesu. I żeby tą definicję odpowiednio zmodyfikować, odpowiednio przerobić w dalszej części tego odcinka, opowiem wam historię.

Prawdziwą historię, która idealnie pokazuje, że budowa systemu od nowa nie zawsze jest trafionym pomysłem. I dlaczego ja tutaj w ogóle poruszam temat budowy systemów od podstaw? Skoro odcinek dotyczy refactoringu kodów w istniejących systemach, poruszam go dlatego, że często w firmach to wygląda właśnie w taki sposób, że refactoringu się unika, bo jest to taka rzecz trochę nieznana, trochę taki wymysł programistów, a potem po czasie jedyna słuszna koncepcja, która jest zawsze proponowana, to jest zbudowanie wszystkiego od podstaw. Uważam, że to nie jest do końca trafiony pomysł w każdym przypadku, stąd chciałbym wam opowiedzieć właśnie historię, która myślę, że dość jasno to zobrazuje.

Mieliśmy takiego klienta z branży e-commerce. System jego już troszeczkę kulał, czyli był zbudowany dawno temu, kiedy firma w ogóle w świecie online dopiero co raczkowała. I z początku, kiedy ruch w tym systemie nie był duży, a system generalnie też nie był jakoś super rozbudowany, to on po prostu działał jak trzeba.

Ale z biegiem czasu, kiedy firma cały czas się rozwijała i system też cały czas się rozwijał w kontekście dodawania kolejnych funkcjonalności, zaczął się mimo tego wszystkiego, mimo tego całego rozwoju, pojawiać dług technologiczny. Czym jest dług technologiczny? O tym opowiadałem w odcinku numer 11. Zatem, jeżeli definicja długu technologicznego nie jest dla ciebie jeszcze jasna, to serdecznie cię do tego odcinka numer 11 odsyłam.

A jeżeli wiesz, czym dług technologiczny jest, to zachęcam cię do słuchania tego odcinka dalej. No i teraz firma była w dużej fazie wzrostu, miała coraz więcej klientów, miała coraz więcej potrzeb biznesowych. Czyli generalnie o to chodzi, prawda? Każdy byłby zadowolony, gdyby nie to, że system po prostu w pewnym momencie przestał wyrabiać.

No i wiecie, coraz większa ilość użytkowników poruszających się w sklepie w tym samym czasie. Więcej danych spływa do tego systemu. Oby system nagle musi wykonywać więcej operacji w tym samym czasie i kolokwialnie mówiąc zamula, nie radzi sobie, wolno działa, nieefektywnie.

No i w rezultacie pojawiają się często błędy, klienci się denerwują, konwersja spada. I tutaj już widzimy pierwszy punkt taki biznesowy, że ta konwersja nam po prostu zaczęła spadać. Właściciel tego systemu był niezadowolony.

No i uwierzcie, to jest sytuacja, która nie jest pojedyncza, bo tak się dzieje praktycznie w każdym biznesie, kiedy nie do końca skalowanie biznesu idzie w parze ze skalowaniem technologii swoich systemów. I teraz oczywiście takie decyzje powinny być podejmowane na poziomie strategicznym, czyli OK, chcemy zwiększyć ruch o 100%, żeby też zwiększyć sprzedaż. Sprawdźmy, czy nasz system jest na to gotowy, bo bez tego ani rusz.

No i idziemy dalej, co się zadziało. Początkowo zalecaliśmy im modernizację obecnych systemów. Proponowaliśmy architekturę mikroserwisową, co pozwalałoby elastycznie skalować poszczególne moduły, czy te poszczególne mikroserwisy, tak aby oddzielić warstwę zakupową od warstwy obsługującej różnego rodzaju elementy zamówień, produktów i jeszcze innych kolejnych elementów tego systemu.

Wszystko szło dobrze i nagle na rynku pojawiła się konkurencyjna firma, która obiecała zbudować zupełnie nową platformę w zaledwie 3 miesiące. Brzmi świetnie, co? Bo było to takim rozwiązaniem na ten ból tego naszego klienta, czyli koniec z awariami, koniec z problemami ze skalowaniem. Takie szybkie rozwiązanie, coś ala tabletka na odchudzanie, ale wyglądająca całkiem realnie.

No ale co się okazało? Ostatecznie prace trwały nie 3, a 6 miesięcy. Czyli taki standard w IT. Ktoś ci podaje termin, pomnóż go razy dwa.

No tylko problem był taki, że rozwiązanie nie zostało zakończone. W sensie prace zostały zakończone, ale okazało się, że tylko 27% funkcjonalności działała poprawnie. Cała reszta albo nie działała w 100% poprawnie, czyli była zaklasyfikowana jako takie pół na pół, albo kompletnie nie działała i to była zdecydowana większość.

Nie działała, czy w ogóle nie była wdrożona. No bo te 3 do 6 miesięcy strasznie mocno się rozjechały. Również w kontekście zakresu, jaki obiecano, kontra dowieziono.

I okazało się, że szybka przebudowa tego systemu zwyczajnie nie wypaliła. Teraz klient nagle był w sytuacji, w której zbliża się szczyt sezonu. W branży, gdzie klient nie ma ani przygotowanego systemu, na którym działa do tej pory.

No bo ten stary system był już utrzymywany w cudzysłowie na trytytki. Tak, żeby on po prostu dojechał do końca w momencie, kiedy ten nowy system będzie włączony. Nie ma też cienia nadziei na to, że ten nowy uda się postawić, no bo tam jest tylko 27% funkcjonalności działających poprawnie.

Na nowy projekt klient wydał naprawdę duże pieniądze. To były budżety idące w setki tysiące złotych. I tak naprawdę, żeby dokończyć potrzebne było drugie tyle.

W sensie, żeby w ogóle dokończyć ten system, który był budowany od podstaw i to tak lekko. I tutaj akurat klient teoretycznie miał obiecane rozliczenie fix price'owe, czyli rozliczenie za efekt. Efektu nie uzyskał.

Sprawa finalnie wylądowała w sądzie. Natomiast koniec końców klient jest przed sezonem, musi sprzedawać. A platforma, którą ma, okazuje się, że mamy na tytytkach, no bo ona miała być zamrożona, wyłączona z końcem tego miesiąca, kiedy firma miała oddać już w 100% działające dzieło.

No i teraz klient finalnie wraca do nas i mówi, dobra wracamy do waszego planu, zaczynamy refaktorować ten stary system zgodnie z planem, który nam zaproponowaliście. Wprowadziliśmy tam architekturę mikroserwisów, daliśmy temu systemowi tak naprawdę drugie życie i long story short, koniec końców ma się świetnie do dzisiaj. Ma on wydzielone odpowiednio warstwy, no i jest stała obsługa tego systemu zapewniona, dzięki czemu może on fajnie działać.

Dodam jeszcze, że udało nam się przygotować system przed szczytem sezonu, więc finalnie sklep, czy w ogóle cały ten biznes, zrealizował swoje cele. A to wszystko właśnie dzięki refaktoryzacji, ale takiej mądrej, w cudzysłowie mądrej. Teraz wracając do definicji z początku tego odcinka, pozwolę sobie ją przypomnieć.

Refactoring to proces restrukturyzacji istniejącego kodu bez zmiany jego zewnętrznego zachowania. I zmieniłbym tą definicję na refactoring to proces restrukturyzacji istniejącego kodu, ale ze zmianą jego zewnętrznego zachowania, uwaga, na lepsze, na zachowanie z korzyścią dla biznesu. Czyli takie właśnie mądre zaplanowanie procesu refaktoryzacji i tego, aby go na stałe wdrożyć do procesów programistycznych dziejących się w obrębie waszego systemu.

I to jest moim zdaniem klucz do sukcesu, jeżeli chodzi o refactoring. Bo jeżeli będziemy ten refactoring robić na zasadzie zróbmy kod po to, żeby był lepszy i on nie da żadnej korzyści biznesowej, no to wtedy siłą rzeczy, jako osoby z biznesu, po co mamy podejmować decyzję o tym refactoringu. Zrobimy to kiedyś, odłóżmy to na kiedyś.

Lepiej wdrożyć dodatkowy feature, dodatkową funkcjonalność, która coś zmieni, jakąś rzecz odblokuje biznesowo. Natomiast długoterminowo trzeba też o to zadbać, bo idąc historią tego właśnie naszego klienta nie znalazłby się w tej sytuacji, gdyby na bieżąco wraz z rozwojem swojego biznesu dbał też o rozwój swojej technologii. No ale koniec końców się udało, więc happy end tutaj zagościł.

I teraz, gdy już wiemy z czym budowa nowego systemu może się wiązać, opowiedzmy sobie pokrótce o korzyściach z refactoringu. Po pierwsze jest to oszczędność. Oszczędność czasu, pieniędzy i nerwów.

Ponieważ refaktoryzacja istniejącego systemu, chyba powinienem powiedzieć mądra refaktoryzacja istniejącego systemu, bo to będzie słowo klucz, jeżeli chodzi o refaktoryzację, często jest znacznie tańsza niż budowa nowego systemu od podstaw. Nie musimy tutaj zaczynać od zera. Wykorzystujemy to co już mamy i to co działa.

To jest trochę jak remont domu zamiast budowy nowego. Zazwyczaj wychodzi taniej i szybciej, chyba że dom jest już w naprawdę absolutnej ruinie. Ale domu nie da się podzielić na mikroserwisy i budować go pokój po pokoju.

Rozwiązanie techniczne, owszem, da się. Po drugie zachowujemy wiedzę biznesową. I to jest moim zdaniem chyba absolutny ewenement i kluczowa rzecz, jeżeli chodzi o refaktoryzację i pracę z istniejącym już kodem.

Ponieważ istniejący system, mimo swoich wad, zawiera w sobie lata doświadczeń i rozwiązań specyficznych dla danego biznesu. I refaktoryzacja pozwala zachować tę cenną wiedzę, jednocześnie poprawiając jakość kodu. I nie ma nic gorszego moim zdaniem niż napisanie drugi raz od nowa, czystej, pachnącej, świeżej aplikacji, która od strony kodu będzie dużo lepsza niż stara aplikacja, ale od strony funkcjonalnej ma te same bolączki, bo nie wyciągnięto wniosków z napisanej już aplikacji wcześniej, tylko po prostu usilnie budowano ją od podstaw, trochę na nowo wykonując te same czynności, które wykonywali poprzednicy w starej aplikacji, tylko na nowej technologii i bez weryfikacji właśnie doświadczeń z wielu, wielu lat pracy poprzedników.

I to jest też niestety sytuacja, z którą się spotkaliśmy kiedyś, że została zbudowana aplikacja zupełnie od podstaw, która miała właśnie zastąpić starą aplikację i okazało się, że powodem chęci napisania tej nowej aplikacji był właśnie jeden z modułów starej aplikacji, który działał bardzo powoli. Był to moduł zamówień dla oproszczenia i w nowej aplikacji klient pierwsze co zrobił, wszedł do tego modułu zamówień i zobaczył, powiedział słuchajcie, no ale ten moduł dalej działa wolno. Tylko to było już pół roku później, kiedy biznes przez pół roku ograniczał inwestycje też dla starego systemu, no po to, żeby poczekać na ten nowy, który miał być szybszy, dużo lepszy.

Tylko tam właśnie nie wyciągnięto tych wniosków i trzeba o tym pamiętać, aby te wnioski wyciągać. Po prostu. Po trzecie stopniowe ulepszanie.

Refaktoryzacja umożliwia wprowadzanie zmian etapami. Nie musimy zatrzymywać całego biznesu na czas przebudowy, ani też nie musimy spowalniać rozwoju tego biznesu, bo refaktoryzacja bardzo fajnie idzie w parze z chęcią rozwoju biznesu, bo wraz właśnie z rozwojem różnych funkcjonalności, które wspierają właśnie biznes w jego rozwoju, możemy też przy okazji dokonywać refaktoryzacji kodu i uważam, że to jest bardzo ważne. Z zastrzeżeniem, że oczywiście uwzględnimy sobie dokładny plan refaktoryzacji i uwzględnimy też, co i dlaczego będziemy refaktoryzować i jak to faktycznie wpłynie na te funkcjonalności biznesowe, czy potrzebne od strony biznesowej.

Taki mały fun fact tutaj dla osób technicznych. Łatwiej jest refaktoryzować obszary, o które akurat pyta biznes, ale to jest taki protip właśnie dla programistów, bo tutaj wynik tej refaktoryzacji jest widoczny wówczas gołym okiem dla menadżerów, czyli przedstawicieli biznesu, a jednocześnie kod jest dużo lepszy, lepiej doprowadzony do stanu funkcjonowania, więc to taki też protip przy okazji tego punktu. Również dla osób technicznych, które nas słuchają.

Mniejsze ryzyko to jest punkt czwarty. Budowa systemu od zera to będzie z reguły duże ryzyko. Szczególnie, oczywiście nie na etapie jego realizacji, tylko na etapie, kiedy trzeba ten system uruchomić, czyli stary system zatrzymać, nowy uruchomić.

I tu jest ten moment największego ryzyka, który trzeba bardzo dobrze sobie przekminić, mówiąc kolokwialnie, ale tak, trzeba go przekminić i się zastanowić, jak to będzie wszystko wyglądało w momencie, kiedy stary system nagle będzie trzeba zatrzymać, dane z niego zmigrować do nowego systemu i ten nowy system uruchomić, zachowując przy tym wszystkim ciągłość działania dla naszego biznesu. No i też zachowując jakiś plan powrotu do starego systemu, gdyby jednak nowy nie był taki piękny i pachnący również od strony biznesowej. I tutaj trzeba wziąć po prostu pod uwagę to, że tak się też może wydarzyć, więc refaktoryzacja często przynosi widoczne efekty znacznie szybciej niż budowa nowego systemu.

I to też trzeba wziąć pod uwagę, że w momencie, kiedy skupiamy się tylko na najbardziej problematycznych obszarach, czyli tak jak w przypadku tej drugiej historii tego modułu zamówień, skupilibyśmy się tylko na nim, to jego można byłoby szybko usprawnić i zaoszczędzić pół roku prac nad systemem całym od podstaw, podczas gdy tylko kilka modułów było takimi uciążliwymi i dało się z nimi coś zrobić. Ale też refaktoryzacja nie zawsze będzie najlepszym rozwiązaniem i taka refaktoryzacja mam na myśli jako działanie ad hoc w systemie, który tej refaktoryzacji wcześniej nie miał. I też chciałbym się podzielić na koniec tego odcinka kilkoma wskazówkami, które jakby wskażą, kiedy warto rozważyć refaktoryzację, a kiedy budowę od nowa.

I refaktoryzacja będzie lepsza, kiedy system generalnie spełnia potrzeby biznesowe, ale ma problemy z wydajnością lub utrzymaniem, mamy ograniczony budżet lub czas, chcemy zachować specyficzne dla biznesu rozwiązania obecne w systemie, system jest duży i skomplikowany, a budowa od nowa byłaby zbyt ryzykowna, ale budowa nowego systemu może być lepsza z kolei, kiedy obecny system jest już bardzo mocno przestarzały technologicznie i nie da się go łatwo zmodernizować lub kiedy potrzeby biznesowe drastycznie się zmieniły i obecny system nie jest w stanie ich spełnić lub kiedy koszty utrzymania obecnego systemu są zbyt wysokie w porównaniu z budową tego systemu zupełnie od podstaw. I tutaj jeszcze bym dołożył taki mały mały punkcik, że możemy sobie zawsze w kontekście refaktoryzacji myśleć też o kwestii na przykład mikroserwisów i o tym, żeby pojedyncze elementy z naszego systemu budować zupełnie od nowa, czyli nie przebudowywać całego systemu wielkiego zupełnie w całości od podstaw na nowy system, tylko jakiś jego jeden wybrany element wyodrębnić jako taki właśnie tak zwany mikroserwis, coś co może działać niezależnie, ale jednocześnie wspierać tą naszą główną aplikację. Jeżeli chciałbyś bądź chciałabyś dowiedzieć się trochę więcej na temat tych mikroserwisów i tego jak sobie poradzić z istniejącą aplikacją, która nie spełnia już Twoich oczekiwań, ale to nie byłby jeszcze czas na pisanie jej od nowa, to serdecznie zapraszam do kontaktu, chętnie powiem Ci trochę więcej na ten temat, no i pomogę wybrać kierunek dla Twoich działań, który będzie dobry dla Twojego biznesu.

To już koniec dzisiejszego odcinka. Kontynuując serię dotyczącą prewencji, myślę, że należałoby sobie zadać pytanie, dlaczego monitoring Twoich systemów to podstawa, czyli czy i w jaki sposób monitorować swoje systemy i w ogóle dlaczego powinniśmy to robić, jakie to ma przełożenie na nasz biznes. I taki właśnie będzie temat odcinka 24.

Zatem zostaw łapkę w górę i subskrypcję, jeżeli interesuje Cię temat tego jak monitorować i dlaczego monitorować Twoje systemy jako taki w ogóle podstawa do prewencji, no aby nie przegapić tego odcinka. Dzięki za przesłuchanie dzisiejszego odcinka. Do usłyszenia za tydzień we wtorek.

Cześć.