W świecie ciągle aktualizowanych systemów operacyjnych, smartfonów, telewizorów, a nawet lodówek, walka z długiem technologicznym toczy się bez przerwy. Jeśli nie zadbamy o ciągły rozwój naszego rozwiązania, a tylko będziemy łatać istniejący kod, dopisywać, kopiować i nadbudowywać go kolejnymi jego liniami, skończymy z wolnym systemem, którego rozwój trwa wieczność i kosztuje majątek.
Artykuł sponsorowany
Dług technologiczny na prostym przykładzie
Jak znaleźć właściwą definicję, a może nawet bardziej metaforę dla długu technicznego związanego z wytwarzaniem oprogramowania? Trzeba przenieść się w czasie. W moim przypadku do pierwszej podróży służbowej. To było kilka miesięcy po rozpoczęciu pracy zawodowej. Kierunek Dhaka – stolica Bangladeszu. Jedno z najbardziej zaludnionych miast świata. Niesamowite przeżycie – po pierwsze kultura zupełnie inna od europejskiej, po drugie konieczność zmierzenia się z wyzwaniami ogromnego miasta. Wiele rzeczy było zaskakujących, ale jedna szczególnie przykuła moją uwagę – całe miasto oplecione pajęczyną kabli elektrycznych oraz telewizyjnych. Ponad 17 mln obywateli potrzebuje przecież dostępu do prądu oraz informacji i rozrywki w postaci telewizji.
Pamiętajmy jednak, że kable potrafią się zerwać, uszkodzić, operatorzy telewizyjni się zmieniają, a usługę trzeba dostarczyć każdemu, kto chce za nią zapłacić. Wtedy zamiast wymienić cały system lub użyć kabli już istniejących, dokłada się nowe – bo szybciej, prościej, taniej. Po kilku takich zabiegach nie ma już innego wyjścia. Jeśli tylko na zbiegu przewodów pojawi się problem, dokładany jest kolejny przewód. Nikt już nie wie, które przewody są używane, a które nie. Ich liczba narasta tworząc fantazyjne obrazy niczym z dzieł Dalego. Może kiedyś ktoś podejmie się zadania i przetnie ten węzeł gordyjski?
Fot. Paweł PanowiczDług technologiczny nie zawsze jest zły
Jak więc dochodzi do powstawania długu technologicznego? Czy zawsze jest to negatywne zjawisko? A może można je świadomie wykorzystać? Tak jak w przypadku powstawania pajęczyny przewodów w Dhace, tak samo w procesie tworzenia oprogramowania możemy zaobserwować podobne mechanizmy powstawania długu. Są to pośpiech, oszczędności, walka o bycie pierwszym na rynku, zmiana wykonawcy systemu w trakcie jego budowy, a w przypadku istniejących systemów – zaniedbywanie jego rozwoju i brak inwestycji w obowiązującą bazę kodu.
Najgorsze co jednak może się wydarzyć, to zaciąganie długu bez świadomości popełniania tej zbrodni na własnym produkcie. Zaciągając kredyt ŚWIADOMIE, traktujemy go jako narzędzie do osiągnięcia celu. A dzięki świadomości, że jest to kredyt, od razu planujemy spłatę – tak samo jak w przypadku kupowania domu czy sprzętu AGD na raty. Intencjonalne używanie długu technologicznego jest szczególnie istotne w projektach typu start-up. W teorii najpierw powinniśmy potwierdzić, czy to nad czym pracujemy, jest komukolwiek potrzebne. W start-upach trzeba iść na skróty, wprowadzić jak najszybciej produkt na rynek, potwierdzić model biznesowy i dopiero zabrać się za poważny rozwój.
Dług technologiczny może stanowić poważne zagrożenie
Jak w takim razie zorientować się, że dług technologiczny zaczyna nas dusić? Jest klika wskaźników, które pomogą nam w tym zadaniu. Pierwszy, najłatwiejszy do zaobserwowania przez managera, to spowolnienie tempa rozwoju projektu. Nawet prosta zmiana urasta do rangi trzydniowego zadania, a programiści mają coraz większy problem ze zrozumieniem, za co odpowiadają zmienne i klasy. Wpływa na to mierna dokumentacja albo jej brak. Kolejny wskaźnik to małe pokrycie funkcjonalności przez testy automatyczne, a dodatkowo permanentne pojawianie się błędów w tym samym miejscu. Podobnie, jeśli suma zamkniętych błędów w danym okresie jest mniejsza niż suma błędów nowych, otwartych, mamy kolejny jasny sygnał, że trzeba się zabrać za redukcję długu. Jeśli większość uchybień dotyczy konkretnego modułu, wiemy gdzie i od czego zacząć. Dosyć prostą metodą jest też konsultacja z liderem technicznym projektu. Jego obserwacje i analiza powinny być zgodne z resztą wskaźników.
Fot. Softserve Źródło: Znajdź czas na refleksję. Nie zapominaj o rewizji projektu
(źródło: materiały wewnętrzne Softserve)Długiem technologicznym można zarządzać
Skupmy się zatem na tym, jak zapobiegać i zarządzać długiem, oraz jakie techniki stosować, aby mieć kontrolę nad wielkością takiego kredytu. Ogromne znaczenie ma sam początek projektu i poznanie ekosystemu, w jakim będziemy utrzymywać dane rozwiązanie. Tak popularne jeszcze do niedawna tworzenie systemów o architekturze typu monoblock, prowadziło równią pochyłą do długu, który narastając niczym śnieżna kula tocząca się po zboczu Nosala, zabijał w końcu projekt. Wybranie właściwej architektury i modelu systemu pozwala na sprawniejsze zarządzanie długiem.
Jeśli zamiast monobloku użyjemy architektury mikrosystemów, będziemy w stanie rozwijać poszczególne, nawet problematyczne bloki, unikając dramatycznego wpływu na inne. Z kolei pracując nad aplikacją mobilną, musimy zdecydować, czy tworzymy ją tylko na Androida, tylko na iOS-a, czy może na oba oprogramowania jednocześnie. Sprawdźmy, jak wygląda cykl życia poszczególnych wersji tych systemów operacyjnych. Jeśli tworzymy aplikację zarówno na Androida, jak i iOS-a, warto wykorzystać nowoczesne rozwiązania, na przykład Flutter od Google. Gdyby jednak wymagania projektu zmusiły nas do zrobienia dwóch natywnych aplikacji, nasze koszty mogą wzrosnąć, ale za to będziemy bardziej konkurencyjni w obszarach, które nas szczególnie interesują.
Dług technologiczny a refactoring
Kiedy nasz projekt jest już dojrzałym bytem lub przejęliśmy go w spadku, z dużą dozą prawdopodobieństwa możemy założyć, że trzeba rozpocząć regularny monitoring poziomu zadłużenia i wprowadzić mechanizmy kontroli. Pomogą nam tutaj wspomniane wcześniej wskaźniki – pokrycie testami, liczba błędów, spadające tempo wdrażania nowych funkcjonalności oraz opór zespołu przed zmianami i dalszym rozwojem systemu. W takiej sytuacji potrzebny jest proces zwany refaktoryzacją (refactoring). Stanowi on połączenie audytu kodu z wprowadzeniem zmian mających na celu ustanowienie wymaganych standardów oraz uporządkowanie i usunięcie nadmiarowych wpisów. Przy refaktoryzacji następuje zmiana kodu źródłowego, ale nie są wprowadzane żadne nowe funkcjonalności. I tutaj mamy do czynienia z najtrudniejszą częścią zarządzania długiem. Z punktu widzenia klienta refaktoring to tylko koszt, programiści pracują, a nowe funkcje czekają…
Często jednak wynikiem refaktoringu jest poprawa wydajności, więc wtedy proces ten może pochwalić się wymiernymi wynikami i łatwiej jest go uzasadnić biznesowo. Jak jeszcze możemy udowodnić realny i pozytywny wpływ refaktoringu na projekt? Jak wspomniałem wcześniej, dług spowalnia wprowadzanie nowych funkcjonalności, a właściwie zaplanowana i wdrożona refaktoryzacja umożliwia ich efektywniejsze wdrożenie, usuwa zależności oraz upraszcza strukturę projektu.
Powstawaniu długu możemy zapobiegać już na etapie tworzenia oprogramowania, wprowadzając tzw. code review. Członkowie zespołu powinni przeglądać wzajemnie kod jeszcze przed wprowadzeniem go do repozytorium. Z zasady człowiek ocenia owoce swojej pracy mniej krytycznie niż innych. Taka wzajemna kontrola poprawia jakość kodu i pomaga zachować wspólne standardy.
Dług technologiczny pojawia się w każdym projekcie IT i jest widoczny na różnych jego etapach. Dług ten możemy zaciągnąć świadomie, zyskując w ten sposób przewagę konkurencyjną już na wczesnym etapie tworzenia i wdrażania nowego rozwiązania. Czasami przejmujemy projekt z widocznym długiem, a czasami narasta on wraz z postępami pracy naszego zespołu. Świat IT nieubłaganie gna do przodu, zmuszając nas do ciągłego rozwoju, a czasami poszukiwania dróg na skróty. Najważniejsze, żeby mieć świadomość, na jakim etapie jest projekt i wykorzystując swoją wiedzę oraz doświadczenie, utrzymywać dług w ryzach.
PS. Nie korzystajmy ciągle z chwilówek!
Senior Project Manager & Delivery Head regionu APAC w SoftServe Poland. Zawodowy integrator – zarówno na płaszczyźnie technologicznej, jak i międzyludzkiej. Doświadczony w zarządzaniu dużymi projektami wdrożeniowymi w branży IT, telekomunikacyjnej i finansowej. W SoftServe odpowiedzialny za rozwój regionu APAC oraz projekty z zakresu IoT, Smart City i Smart Transportation. Zapalony perkusista i majsterkowicz. Nic co drewniane nie jest mu obce.