System działa. Użytkownicy mogą się logować, zamówienia są obsługiwane, dane trafiają do odpowiednich miejsc, a pracownicy wykonują swoją codzienną pracę. Z pozoru wszystko jest więc w porządku.
Problem pojawia się wtedy, gdy dodanie niewielkiej funkcji zaczyna wymagać wielu godzin analizy, aktualizacja jednej biblioteki powoduje problemy w innych częściach aplikacji, wdrożenia stają się coraz bardziej ryzykowne, a kolejny software developer potrzebuje tygodni, aby zrozumieć zależności w systemie.
To mogą być objawy długu technologicznego.
Dług technologiczny, określany również jako dług techniczny lub technical debt, oznacza konsekwencje wcześniejszych decyzji technologicznych, architektonicznych i programistycznych, które utrudniają dalsze utrzymanie lub rozwój oprogramowania. Nie musi oznaczać, że system został źle wykonany. Część kompromisów może być podjęta świadomie – na przykład po to, aby szybciej uruchomić MVP albo dostarczyć kluczową funkcję. Problem zaczyna się wtedy, gdy takich kompromisów przybywa, a organizacja nie uwzględnia ich późniejszego uporządkowania.
W efekcie firma zaczyna płacić swego rodzaju technologiczne „odsetki”: kolejne zmiany wymagają więcej pracy, ryzyko błędów rośnie, a możliwości rozwoju systemu są coraz mocniej ograniczone.
Dlatego dług technologiczny jest nie tylko problemem programistycznym. Może stać się problemem biznesowym, operacyjnym i finansowym całej organizacji.
W tym artykule przeczytasz:
Dług technologiczny to określenie konsekwencji decyzji, które ułatwiają lub przyspieszają realizację projektu w danym momencie, ale mogą zwiększać koszt jego późniejszego utrzymania i rozwoju.
Najprostszy przykład?
Zespół ma dwa tygodnie na wdrożenie kluczowej funkcjonalności.
Może przygotować rozwiązanie bardziej uniwersalne i łatwe do dalszego rozwijania, ale wymaga to dodatkowego czasu. Może też stworzyć rozwiązanie prostsze, spełniające aktualne wymagania, ale wymagające późniejszego uporządkowania.
Druga decyzja nie musi być błędem.
Jeżeli jest świadoma, odpowiednio udokumentowana i firma planuje powrót do danego elementu systemu, może być racjonalnym kompromisem biznesowym.
Dług powstaje wtedy, gdy kompromis pozostaje w systemie. Jeżeli takich decyzji pojawia się coraz więcej, system zaczyna stopniowo tracić elastyczność. Każda kolejna zmiana musi uwzględniać wcześniejsze ograniczenia, wyjątki i zależności. Właśnie dlatego metafora długu jest tak trafna.
Firma otrzymała wcześniej korzyść – na przykład szybsze wdrożenie – ale później może ponosić koszt tej decyzji przy kolejnych zmianach.
W polskich publikacjach można spotkać oba określenia: dług techniczny oraz dług technologiczny. W praktyce najczęściej odnoszą się one do tego samego zjawiska określanego po angielsku jako technical debt.
Sam problem jest jednak szerszy niż „stary kod”.
Dług może dotyczyć między innymi:
Dlatego w rozbudowanym systemie informatycznym można mieć świetnie napisany fragment kodu, a jednocześnie duży dług technologiczny wynikający z przestarzałej architektury albo zależności od niewspieranej technologii.
Nie. To jedno z najważniejszych rozróżnień. System informatyczny może posiadać dług technologiczny, mimo że w momencie powstawania został zaprojektowany prawidłowo.
Technologia się zmienia. Zmienia się również firma. System, który pięć lat temu obsługiwał kilkuset klientów i jeden kanał sprzedaży, może dzisiaj obsługiwać kilkadziesiąt tysięcy użytkowników, kilka rynków, integrację z ERP, system CRM, magazyn, marketplace, aplikację mobilną oraz inne rozwiązania.
Problem nie musi więc polegać na tym, że ktoś wcześniej popełnił błąd. Może polegać na tym, że architektura zaprojektowana dla dawnych potrzeb przestała odpowiadać aktualnej skali biznesu.
Dług technologiczny jest zatem w wielu systemach naturalnym skutkiem ich wieloletniego rozwoju. Nie oznacza to jednak, że należy go ignorować.
Nie istnieje jedna przyczyna. W większości rozwijanych przez lata systemów informatycznych dług powstaje stopniowo i jest efektem wielu mniejszych decyzji.
Jednym z najczęstszych powodów jest konieczność dostarczenia rozwiązania w bardzo krótkim terminie. Biznes potrzebuje nowej funkcjonalności przed rozpoczęciem kampanii, wejściem na nowy rynek, targami albo podpisaniem umowy z ważnym klientem.
Zespół świadomie upraszcza rozwiązanie. Samo w sobie nie musi być to problemem. Problem pojawia się, gdy rozwiązanie „tymczasowe” pozostaje częścią architektury przez kolejne lata.
Systemy informatyczne ewoluują. Dochodzi nowy moduł. Potem integracja. Kolejny typ klienta. Następny kanał sprzedaży. Nowe role użytkowników. Kolejna wersja procesu.
Jeżeli każda nowa funkcjonalność jest po prostu dokładana do istniejącej konstrukcji, bez okresowej analizy architektury, wraz z rozwojem projektu może rosnąć liczba wzajemnych zależności. W pewnym momencie nawet niewielka modyfikacja zaczyna wymagać ingerencji w wiele obszarów aplikacji.
Wieloletni system może być rozwijany przez kilka różnych firm i wielu programistów. Każdy zespół może pracować według innych standardów, korzystać z innych wzorców albo inaczej interpretować pierwotne założenia. Jeżeli brakuje spójnej architektury, dokumentacji i procesu code review, kolejne warstwy systemu zaczynają coraz bardziej się od siebie różnić.
Backlog niemal zawsze zawiera funkcje biznesowe, które łatwiej uzasadnić niż prace techniczne.
„Dodajmy nową metodę płatności” brzmi dla organizacji bardziej konkretnie niż: „uporządkujmy moduł odpowiedzialny za obsługę płatności”.
Jeżeli każda godzina developmentu przeznaczana jest wyłącznie na nowe funkcje, potrzeba porządkowania istniejącego kodu stopniowo narasta.
Zmiana kodu jest znacznie bardziej ryzykowna, jeśli software developer nie może szybko sprawdzić, czy nie wpłynęła na inne funkcje systemu.
W takiej sytuacji zespół zaczyna unikać zmian w newralgicznych obszarach. Im większy jest system, tym większy może być koszt regresji.
Nieaktualizowane zależności mogą z czasem utrudnić aktualizację całej aplikacji. Problem jest szczególnie widoczny wtedy, gdy pomiędzy używaną wersją frameworka a aktualną wersją pojawiło się kilka dużych wydań.
Aktualizacja, która wykonywana regularnie byłaby stosunkowo niewielkim zadaniem, po kilku latach może zamienić się w osobny projekt.
Systemy firmowe bardzo rzadko funkcjonują w izolacji. Sklep może komunikować się z ERP, CRM, WMS, systemem płatniczym, przewoźnikami, systemem marketing automation oraz marketplace.
Jeśli każda integracja rozwijana jest niezależnie, bez wspólnego podejścia do wymiany danych, logowania błędów, kolejkowania czy ponawiania operacji, wraz ze wzrostem liczby połączeń wzrasta także złożoność całej platformy.
Dokumentacja nie zastępuje czytelnego kodu, ale w rozbudowanych systemach pozwala zachować wiedzę o decyzjach architektonicznych, integracjach, procesach i zależnościach.
Bez niej część wiedzy może istnieć wyłącznie w głowie jednego developera. Jest to nie tylko dług technologiczny, lecz również realne ryzyko organizacyjne.
System został zaprojektowany jako B2C, a firma rozwija sprzedaż B2B. Aplikacja obsługiwała jeden kraj, a teraz ma działać w pięciu.
Sklep miał kilka tysięcy produktów, a obecnie posiada kilkaset tysięcy wariantów. System nie musi być źle zaprojektowany. Zmienił się po prostu problem, który ma rozwiązywać.
Narzędzia oparte na AI mogą usprawniać pracę programistyczną, ale sam fakt szybszego generowania kodu nie rozwiązuje problemów architektonicznych. Jeżeli fragmenty kodu są dodawane bez review, testów, znajomości architektury oraz oceny wpływu na pozostałe moduły, szybkość produkowania kolejnych funkcji może również przyspieszać powstawanie niespójności.
AI nie jest więc automatycznie ani źródłem, ani lekarstwem na dług technologiczny. Kluczowy pozostaje sposób prowadzenia projektu.
Dług technologiczny warto rozpatrywać szerzej niż wyłącznie jako jakość kodu.
To fragmenty kodu trudne do zrozumienia, powielone, nadmiernie skomplikowane lub posiadające wiele wyjątków.
Ich zmiana wymaga więcej czasu i zwiększa ryzyko wprowadzenia błędów.
Dotyczy sposobu, w jaki zbudowany jest cały system. Może obejmować nadmierne zależności pomiędzy modułami, źle rozdzieloną odpowiedzialność, ograniczenia skalowalności albo architekturę niedostosowaną do obecnych procesów biznesowych.
Jest często bardziej kosztowny niż pojedyncze problemy w kodzie, ponieważ wpływa na dużą część systemu.
Powstaje, gdy projekt korzysta z przestarzałych wersji frameworków, bibliotek, komponentów lub środowiska.
Im dłużej aktualizacja jest odkładana, tym większa może być różnica pomiędzy używaną a aktualną wersją.
System posiada niewystarczające testy jednostkowe, integracyjne lub end-to-end.
W efekcie zespół musi wykonywać więcej testów ręcznych, a wdrożenie zmian staje się bardziej ryzykowne.
Brakuje aktualnego opisu architektury, API, procesów, integracji lub środowiska.
Onboarding kolejnego software developera zajmuje więcej czasu, a część decyzji trzeba odtwarzać na podstawie kodu.
Dotyczy serwerów, konteneryzacji, środowisk, sposobu deploymentu, backupów, monitoringu i innych elementów DevOps.
System może wykorzystywać nowoczesne technologie, a jednocześnie być wdrażany za pomocą procesu podatnego na błędy.
Pojawia się szczególnie w systemach powiązanych z ERP, CRM, e-commerce, magazynami lub zewnętrznymi API.
Brak standardów wymiany danych, logowania, obsługi wyjątków i mechanizmów ponawiania może powodować problemy operacyjne trudne do zdiagnozowania.
Nieprzemyślany model danych, duplikaty, brak odpowiednich indeksów, niespójne formaty albo wielokrotne przechowywanie tych samych informacji mogą istotnie utrudnić dalszy rozwój systemu.
Nie. Legacy system, czyli system odziedziczony lub starszy system informatyczny, nie musi automatycznie oznaczać systemu złej jakości. Aplikacja może mieć wiele lat i nadal być stabilna, odpowiednio utrzymywana i dobrze dopasowana do potrzeb organizacji.
Z drugiej strony stosunkowo młody projekt może posiadać bardzo duży dług technologiczny. Wiek systemu jest więc tylko jednym z czynników. Znacznie ważniejsze jest pytanie: czy system można bezpiecznie utrzymywać i rozwijać w tempie odpowiadającym potrzebom biznesu?
Jeżeli odpowiedź brzmi „tak”, sam fakt wykorzystania starszej technologii nie musi uzasadniać kosztownej przebudowy.
Sam wiek technologii nie przesądza o konieczności przebudowy systemu. W Webtom.pl przejmujemy i rozwijamy również istniejące projekty – analizujemy kod, architekturę, integracje i możliwości dalszego rozwoju, zanim zaproponujemy konkretny kierunek zmian.
Dług technologiczny rzadko objawia się jednym spektakularnym problemem. Znacznie częściej widoczny jest w codziennej pracy nad systemem.
Funkcja, która biznesowo wydaje się niewielka, wymaga modyfikacji kilku modułów, przygotowania wielu wyjątków i długich testów regresyjnych.
Zespół nie ma pewności, czy zmiana jednego elementu nie wpłynie na funkcję pozornie z nim niezwiązaną.
W projekcie pojawiają się obszary, o których zespół mówi: „tego lepiej nie ruszać”. To bardzo czytelny sygnał.
Projekt pozostaje kilka dużych wersji za aktualnym środowiskiem, a każda kolejna aktualizacja jest odkładana, ponieważ wymagałaby zbyt wielu zmian.
System jest na tyle niespójny lub słabo udokumentowany, że zrozumienie podstawowych zależności zajmuje tygodnie.
Awaria, urlop lub odejście tej osoby może istotnie ograniczyć możliwość utrzymania systemu.
Problem jest naprawiany w jednym miejscu, ale pojawia się w innym albo powraca przy kolejnej zmianie.
Dotyczy to często połączeń z ERP, CRM albo starym API.
Integracja spełnia swoją funkcję, jednak jej logika jest na tyle złożona lub słabo udokumentowana, że każda zmiana budzi obawy.
Im większa aplikacja, tym trudniej ręcznie zweryfikować wszystkie scenariusze po każdej zmianie.
Backlog funkcjonalny rośnie, ale większość dostępnego czasu pochłaniają błędy, awarie, obejścia i problemy techniczne.
Firma chce uruchomić nowy model sprzedaży, integrację lub usługę, ale ograniczenia istniejącego rozwiązania powodują, że wdrożenie staje się nieproporcjonalnie kosztowne.
Każda estymacja zawiera bardzo duży margines niepewności, ponieważ zespół nie zna wszystkich zależności i możliwych skutków modyfikacji.
Pojedynczy punkt z tej listy nie oznacza jeszcze poważnego problemu. Jeżeli jednak występuje ich kilka jednocześnie, warto przeanalizować techniczny stan systemu.
Największym błędem jest traktowanie długu technologicznego jako wewnętrznego problemu developerów. Jego konsekwencje mogą być widoczne w całej organizacji.
Schemat jest prosty: większa złożoność techniczna → więcej czasu potrzebnego na development → większy koszt zmiany → wolniejsze wdrożenia → ograniczona możliwość reagowania na potrzeby rynku.
Wyobraźmy sobie dwie aplikacje realizujące podobny proces. W pierwszej dodanie funkcjonalności wymaga analizy jednego modułu, implementacji i testów. W drugiej ta sama zmiana wymaga dodatkowo sprawdzenia kilku starych zależności, przygotowania obejścia dla niewspieranej biblioteki, ręcznego przetestowania powiązanych procesów oraz ostrożnego wdrożenia.
Funkcja biznesowa jest identyczna.Koszt jej wytworzenia – już nie. To właśnie w ten sposób organizacja zaczyna płacić „odsetki” od długu technologicznego.
Nie istnieje uniwersalny przelicznik pozwalający powiedzieć, że firma posiada dług technologiczny o wartości dokładnie 100.000 czy 500.000 zł. Można jednak analizować jego koszt pośrednio.
Warto obserwować przede wszystkim:
Można przyjąć prostą zasadę: kosztem długu technologicznego nie jest wyłącznie koszt jego usunięcia. Kosztem są również wszystkie dodatkowe roboczogodziny, ryzyka i utracone możliwości, które powstają dlatego, że dług pozostaje w systemie.
Nie warto sprowadzać całej oceny do jednej liczby wygenerowanej przez narzędzie analizujące kod. Analiza statyczna może być wartościowym źródłem informacji, ale dług technologiczny dotyczy również architektury, infrastruktury, testów, procesów i wpływu systemu na biznes.
Dlatego warto połączyć kilka perspektyw.
Ta ostatnia perspektywa jest szczególnie ważna. Nie każdy problem techniczny wymaga natychmiastowej naprawy.
Na potrzeby wstępnej analizy systemu można przyjąć pięć poziomów długu technologicznego. Nie jest to formalna norma ani uniwersalna klasyfikacja branżowa. To praktyczny model, który pozwala połączyć stan technologii z wpływem na dalszy rozwój biznesu.
System posiada niewielkie kompromisy technologiczne, ale nie wpływają one istotnie na jego rozwój. Zespół wie o ich istnieniu. Najważniejsze obszary są udokumentowane. Zmiany są przewidywalne.
Rekomendacja: monitorować i porządkować w ramach bieżącego developmentu.
Niektóre obszary zaczynają wymagać dodatkowego czasu. Pojawiają się starsze zależności albo fragmenty wymagające refaktoryzacji. Nie blokuje to jednak realizacji roadmapy produktu.
Rekomendacja: umieścić prace techniczne w backlogu i systematycznie ograniczać zadłużenie.
Problemy techniczne mają już zauważalny wpływ na budżet. Zmiany wymagają dodatkowych analiz. Wzrasta zakres testów manualnych. Developerzy tworzą kolejne obejścia dla wcześniejszych ograniczeń.
Rekomendacja: przeprowadzić audyt techniczny i przygotować plan modernizacji najbardziej kosztownych obszarów.
Architektura systemu ogranicza możliwość realizacji nowych funkcji albo znacząco zwiększa ich koszt. Firma rezygnuje z części pomysłów ze względu na ograniczenia technologiczne. Aktualizacje są odkładane, a kluczowe moduły stają się coraz trudniejsze w utrzymaniu.
Rekomendacja: przygotować roadmapę modernizacji systemu i rozważyć przebudowę wybranych modułów.
Dług technologiczny wpływa na bezpieczeństwo, stabilność lub możliwość dalszego utrzymywania systemu. Technologia może być niewspierana, wiedza skupiona wokół pojedynczych osób, a kolejne zmiany powodować nieakceptowalne ryzyko.
Rekomendacja: potraktować problem jako ryzyko biznesowe i podjąć decyzję pomiędzy gruntowną modernizacją a stopniową wymianą systemu.
Nie. I właśnie to odróżnia świadome zarządzanie systemem od bezrefleksyjnego „poprawiania wszystkiego”.
Nie każdy fragment starego kodu musi zostać zrefaktoryzowany. Jeżeli moduł:
jego przebudowa może mieć bardzo niski priorytet.
Z biznesowego punktu widzenia ważniejsze może być uporządkowanie obszaru, który jest zmieniany co tydzień i regularnie powoduje problemy. Dlatego dług technologiczny powinien być priorytetyzowany, a nie automatycznie likwidowany.
Kluczowe pytanie brzmi: ile kosztuje pozostawienie danego długu w systemie w stosunku do kosztu jego usunięcia?
Dobrą praktyką jest ocena każdego istotnego problemu w kilku wymiarach.
Problem w module rozwijanym każdego tygodnia będzie generował znacznie więcej „odsetek” niż problem w funkcji, która praktycznie się nie zmienia.
Im więcej zależności, tym wyższe ryzyko.
Problemy dotyczące bezpieczeństwa powinny otrzymać wyższy priorytet niż kwestie estetyki kodu.
Brak wsparcia frameworka, biblioteki lub komponentu może z czasem ograniczyć możliwość aktualizacji pozostałych elementów.
Jeśli określona część architektury utrudnia realizację ważnych funkcjonalności, koszt dalszego odkładania zmian może szybko rosnąć.
To pytanie najlepiej oddaje finansową metaforę długu.
Rozpoznanie długu technologicznego to dopiero pierwszy etap. Następnie trzeba zdecydować, co właściwie zrobić z istniejącym systemem.
Nie zawsze odpowiedzią powinien być rewrite.
Refaktoryzacja polega na poprawie wewnętrznej struktury istniejącego kodu bez zmiany jego podstawowego zachowania z punktu widzenia użytkownika. Sprawdza się wtedy, gdy fundament systemu jest nadal odpowiedni, ale wybrane elementy wymagają uporządkowania.
Może obejmować między innymi:
Jeżeli chcesz dokładniej poznać ten proces, osobno opisaliśmy, czym jest refaktoryzacja kodu i kiedy warto ją stosować.
Modernizacja jest pojęciem szerszym. Może obejmować refaktoryzację, ale również:
To dobre rozwiązanie, jeśli system nadal dostarcza biznesową wartość, ale jego techniczne fundamenty wymagają stopniowego unowocześnienia.
Nie zawsze trzeba modernizować wszystko. Często najlepszym rozwiązaniem jest pozostawienie stabilnej części systemu i stopniowa wymiana elementów generujących największe problemy.
Przykładowo można przebudować:
bez przepisywania całej aplikacji.
Rewrite powinien być traktowany jako jedna z dostępnych możliwości, a nie domyślna odpowiedź na dług technologiczny.
Napisanie systemu od początku może mieć sens, gdy:
Trzeba jednak pamiętać o jednym. Stary system zawiera wiele lat wiedzy biznesowej. Nie tylko w dokumentacji. Również w wyjątkach, regułach, walidacjach i zachowaniach, których znaczenie może nie być od razu widoczne. Przepisanie systemu od początku oznacza konieczność ponownego odkrycia części tej wiedzy.
Dlatego decyzję o rewrite warto podejmować dopiero po analizie.
Software developer nie zajmuje się wyłącznie tworzeniem nowych funkcjonalności. W dojrzałym projekcie jego zadaniem jest również dbanie o to, aby kolejne zmiany nie obniżały możliwości dalszego rozwoju systemu.
W praktyce oznacza to między innymi:
Jednocześnie odpowiedzialności za dług technologiczny nie powinno się przerzucać wyłącznie na programistów. Software developer może wskazać problem, ale to organizacja decyduje, jak dzielić budżet pomiędzy rozwój nowych funkcji i utrzymanie technicznej jakości systemu.
W niewielkim projekcie – czasami tak. W rozbudowanym systemie problem zwykle wykracza poza sam kod.
Potrzebna może być wiedza dotycząca:
Dlatego przy dużym długu technologicznym problemem nie zawsze jest brak kolejnego programisty. Czasem potrzebny jest zespół potrafiący spojrzeć na system jako całość.
Software house może być dobrym rozwiązaniem przede wszystkim wtedy, gdy firma posiada działający system, ale potrzebuje szerszych kompetencji do jego dalszego rozwoju lub modernizacji.
Dotyczy to szczególnie sytuacji, w których:
W takim przypadku zadaniem software house’u nie powinno być rozpoczęcie od stwierdzenia: „trzeba napisać wszystko od nowa”.
Znacznie rozsądniejsze jest rozpoczęcie od poznania systemu. Jeśli chcesz szerzej poznać zakres odpowiedzialności takiego zespołu, zobacz również, czym jest software house i jakie projekty realizuje.
Przejęcie projektu po innym wykonawcy jest zupełnie inną sytuacją niż tworzenie nowej aplikacji.
Pierwszym etapem powinno być ograniczenie niewiedzy.
Potrzebne mogą być między innymi:
Zespół powinien zrozumieć sposób budowania i uruchamiania aplikacji oraz zależności infrastrukturalne.
Trzeba ustalić między innymi:
Nie chodzi wyłącznie o znalezienie „brzydkiego kodu”.
Ważniejsze jest zidentyfikowanie miejsc, które mogą utrudniać późniejszy development.
Przy systemach B2B, e-commerce i aplikacjach biznesowych integracje mogą odpowiadać za dużą część ryzyka technologicznego.
W szczególności warto zweryfikować połączenia z ERP, CRM, magazynami, płatnościami i zewnętrznymi API.
Zanim rozpocznie się większą modernizację, warto wiedzieć, czy obecne zachowanie systemu można bezpiecznie kontrolować.
Sposób wdrażania zmian może być równie ważny jak sam kod.
Nie każdy znaleziony problem ma ten sam priorytet.
Ryzyka warto rozdzielić na przykład na:
Dopiero po analizie można sensownie odpowiedzieć na pytanie: co naprawiamy teraz, co później, czego nie ruszamy, a co należy przebudować?
To znacznie bardziej wartościowe niż tworzenie listy wszystkich technicznych niedoskonałości systemu.
Dobry audyt nie powinien kończyć się dokumentem zawierającym kilkaset uwag bez wskazania ich znaczenia.
Firma potrzebuje odpowiedzi na pytania biznesowe. Przede wszystkim:
Efektem powinna być roadmapa działań, a nie samo stwierdzenie, że w systemie istnieje dług technologiczny.
Im dłużej rozwijany jest system, tym większe znaczenie ma sposób zarządzania jego jakością techniczną. W pierwszych miesiącach projektu większość developmentu może dotyczyć nowych funkcji.
Po kilku latach część pracy nieuchronnie zaczyna dotyczyć:
To normalny etap życia oprogramowania. Błędem jest zakładanie, że kilkuletni system można rozwijać dokładnie tak samo jak projekt posiadający trzy miesiące.
Dojrzały rozwój systemów informatycznych oznacza umiejętność równoważenia trzech potrzeb:
Stały maintenance może ograniczać narastanie części długu technologicznego. Nie chodzi wyłącznie o wykonywanie aktualizacji.
Profesjonalne utrzymanie systemu może obejmować również:
Regularne wykonywanie takich prac jest zazwyczaj prostsze niż kilkuletnie odkładanie zmian i późniejsza duża modernizacja. Dlatego w przypadku rozwiązań istotnych dla działalności firmy warto traktować maintenance stron, sklepów i systemów webowych jako element cyklu życia systemu, a nie tylko usługę wykonywaną po awarii.
Całkowite wyeliminowanie długu technologicznego prawdopodobnie nie byłoby ani realistyczne, ani ekonomicznie uzasadnione.
Można nim jednak zarządzać.
Problemy powinny być zapisane, opisane i priorytetyzowane.
Jeżeli znajdują się wyłącznie w pamięci developerów, organizacja nie ma nad nimi kontroli.
Nie każda refaktoryzacja wymaga osobnego dużego projektu.
Wiele problemów można usuwać stopniowo przy okazji pracy nad konkretnym modułem.
Mniejsze, częstsze aktualizacje zwykle ułatwiają kontrolę zmian w porównaniu z kilkuletnim skokiem pomiędzy wersjami.
Testy zwiększają pewność podczas zmian i pozwalają bezpieczniej modernizować istniejący system.
Druga osoba może zauważyć problemy, które nie są oczywiste dla autora rozwiązania.
Nie trzeba dokumentować każdej linii kodu.
Warto jednak zachowywać informacje odpowiadające na pytanie: „dlaczego zrobiliśmy to właśnie w taki sposób?”.
Frameworki, biblioteki, API i usługi zewnętrzne mają własne cykle życia.
Ich aktualność powinna być elementem utrzymania projektu.
Nowoczesność technologii nie gwarantuje, że będzie najlepszym rozwiązaniem dla danego projektu.
Znacznie ważniejsze są:
Jeżeli przez kilka lat 100% dostępnego developmentu przeznaczane jest na nowe funkcjonalności, techniczne zaległości będą miały coraz mniej przestrzeni na uporządkowanie.
Integracje są szczególnym źródłem złożoności. Nie kontrolujemy bowiem wyłącznie własnego systemu.
Zależymy również od:
W rozbudowanych integracjach z systemami ERP szczególne znaczenie ma więc odpowiednia obsługa błędów, logowanie zdarzeń, synchronizacja oraz możliwość ponawiania operacji.
Dobrze zaprojektowana integracja powinna zakładać nie tylko scenariusz: „wszystko działa”. Musi również odpowiadać na pytanie: co stanie się z procesem, kiedy drugi system przez 20 minut nie odpowiada?
Takie decyzje mają później duży wpływ na koszt utrzymania rozwiązania.
Dedykowane systemy B2B często rozwijają się przez wiele lat. Początkowo mogą służyć wyłącznie do składania zamówień.
Później pojawiają się:
To przykład systemu, w którym niewłaściwe dokładanie kolejnych funkcji może powodować szybki wzrost złożoności.
W przypadku systemów dedykowanych i platform B2B szczególne znaczenie ma więc projektowanie architektury z uwzględnieniem dalszego rozwoju, a nie wyłącznie obecnej listy wymagań.
Rosnący koszt zmian nie zawsze oznacza, że system trzeba napisać od nowa. Możemy przeanalizować jego architekturę, kod i integracje oraz wskazać, które elementy warto dalej rozwijać, zmodernizować lub przebudować.
Dług technologiczny nie dotyczy wyłącznie aplikacji tworzonych od podstaw. Może pojawiać się również w WordPress i WooCommerce.
Przykładem może być serwis rozwijany przez kilka lat poprzez dokładanie kolejnych wtyczek.
Każda z osobna rozwiązuje konkretny problem. Po pewnym czasie system posiada jednak kilkadziesiąt rozszerzeń, zależności pomiędzy nimi, własne modyfikacje, niestandardowe skrypty oraz elementy, których nikt nie chce aktualizować w obawie przed awarią.
Typowe źródła długu w takich projektach to między innymi:
Rozwiązaniem nie zawsze jest migracja z WordPressa.
Czasami wystarczy uporządkowanie architektury, ograniczenie zależności albo zastąpienie kilku rozszerzeń jednym dedykowanym rozwiązaniem. Przy bardziej niestandardowych wymaganiach właściwym kierunkiem może być również Custom WordPress Development – rozwój dedykowanych funkcji, modułów i integracji bez dokładania kolejnych przypadkowych zależności.
W innych przypadkach dalszy rozwój na istniejącej podstawie może jednak przestać być racjonalny. Decyzję warto podejmować na podstawie analizy, a nie samej liczby wtyczek.
W sklepie internetowym problem jest dodatkowo związany z krytycznymi procesami sprzedażowymi.
System może odpowiadać za:
Im więcej elementów jest ze sobą powiązanych, tym bardziej kosztowne mogą być niekontrolowane kompromisy techniczne. Dług technologiczny w e-commerce może więc oddziaływać bezpośrednio na proces sprzedaży.
Dlatego rozbudowany WooCommerce powinien być traktowany jak system biznesowy, a nie wyłącznie „strona z wtyczką sklepu”. Jeżeli taki sklep ma być dalej rozwijany, integrowany z innymi systemami lub rozbudowywany o dedykowane procesy sprzedażowe, zobacz również, jak projektujemy i programujemy sklepy WooCommerce dla firm.
Nie automatycznie. Zmiana monolitu na mikroserwisy nie jest uniwersalnym lekarstwem.
Mikroserwisy mogą zwiększyć możliwość niezależnego rozwijania wybranych domen, ale jednocześnie wprowadzają własną złożoność:
Jeżeli problemem jest źle rozumiana domena biznesowa albo brak standardów developmentu, rozdzielenie systemu na kilkanaście usług może jedynie przenieść problem w inne miejsce. Architektura powinna wynikać z potrzeb projektu. Nie z mody.
Również nie. Migracja z technologii A do technologii B sama w sobie nie rozwiązuje problemu. Można przepisać system w najnowszym frameworku i w ciągu kilkunastu miesięcy ponownie doprowadzić do dużego długu technologicznego.
Najważniejsze są:
Technologia jest narzędziem.
Szczególnie dobrym momentem jest sytuacja, w której firma:
Audyt wykonany przed dużą inwestycją może pomóc określić, czy nowe funkcjonalności powinny powstawać na obecnej architekturze.
Dług technologiczny jest dobrym przykładem problemu, w którym samo zwiększenie liczby programistów nie zawsze przyspieszy projekt.
Jeżeli przyczyna znajduje się w architekturze, najpierw trzeba ją zrozumieć.
Jeżeli problemem są integracje – przeanalizować przepływ danych.
Jeżeli system posiada niewiele testów – stworzyć bezpieczniejszy sposób wprowadzania zmian.
Dopiero później można zwiększać tempo developmentu. Dlatego przy przejmowaniu i modernizacji złożonych systemów ważna jest współpraca osób odpowiedzialnych za różne obszary projektu: software developerów, architektów, DevOps, testerów, UX/UI i osób rozumiejących proces biznesowy. Tak właśnie powinien działać doświadczony software house. Nie zaczynać od technologii. Zacząć od problemu.
Przy istniejącym systemie pierwszym celem powinno być zrozumienie jego rzeczywistego stanu oraz potrzeb biznesowych firmy. Nie zakładamy z góry, że każdy starszy system trzeba przepisać.
W zależności od sytuacji właściwym kierunkiem może być:
Jako software house możemy wspierać zarówno tworzenie nowych rozwiązań, jak i dalszy rozwój istniejących systemów informatycznych. W przypadku projektu, którego nie tworzyliśmy od początku, kluczowe znaczenie ma analiza. Dopiero po poznaniu kodu, architektury, integracji, środowiska i celów biznesowych można odpowiedzialnie rekomendować kolejne kroki.
Dług technologiczny nie jest czymś, czego można całkowicie uniknąć w rozwijanym przez lata oprogramowaniu. Zmieniają się technologie, wymagania biznesowe, skala działania firmy i sposób wykorzystywania systemu. Kluczowe znaczenie ma więc nie samo istnienie długu, ale jego wpływ na dalszy rozwój systemu informatycznego.
Jeżeli nowe funkcjonalności powstają coraz wolniej, aktualizacje stają się ryzykowne, kolejne integracje wymagają coraz większej liczby obejść, a utrzymanie systemu pochłania rosnącą część budżetu, warto sprawdzić, gdzie rzeczywiście znajduje się problem.
Nie zawsze potrzebne jest napisanie aplikacji od nowa. Czasem wystarczy refaktoryzacja konkretnego modułu, aktualizacja technologii, przebudowa integracji albo uporządkowanie procesu developmentu. W innych przypadkach konieczna może być szersza modernizacja systemu.
Świadome zarządzanie długiem technologicznym nie oznacza ciągłego przepisywania kodu. Oznacza podejmowanie decyzji na podstawie rzeczywistego stanu systemu, kosztów oraz jego znaczenia dla biznesu. Dobrze zarządzany dług technologiczny nie musi blokować rozwoju. Niekontrolowany może natomiast sprawić, że każda kolejna zmiana będzie kosztowała więcej niż poprzednia.
Dług technologiczny to konsekwencja wcześniejszych decyzji dotyczących kodu, architektury, technologii lub sposobu rozwoju systemu, która zwiększa koszt jego późniejszego utrzymania albo rozbudowy. Może wynikać zarówno ze świadomych kompromisów, jak i nieprzewidzianych zmian zachodzących podczas wieloletniego rozwoju oprogramowania.
W praktyce oba określenia najczęściej używane są jako polskie odpowiedniki terminu technical debt. Dług technologiczny może dotyczyć znacznie więcej niż samego kodu – również architektury, infrastruktury, testów, dokumentacji, integracji i zależności.
Typowe sygnały to rosnący czas potrzebny na wdrażanie zmian, problemy podczas aktualizacji, częste błędy regresyjne, brak testów, przestarzałe zależności, trudny onboarding developerów oraz sytuacje, w których architektura systemu ogranicza możliwość realizacji nowych funkcjonalności.
W rozwijanych przez wiele lat systemach pewien poziom kompromisów technicznych jest naturalny. Samo istnienie długu nie musi być problemem. Kluczowe jest to, czy pozostaje pod kontrolą i czy nie generuje kosztów nieproporcjonalnych do wartości systemu.
Nie. Niektóre elementy długu mogą mieć minimalny wpływ na system i ich usunięcie nie będzie ekonomicznie uzasadnione. Priorytet powinny mieć te problemy, które zwiększają koszty, ryzyko, utrudniają development albo blokują istotne potrzeby biznesowe.
Refaktoryzacja może ograniczyć dług związany ze strukturą kodu, ale dług technologiczny może dotyczyć również architektury, infrastruktury, zależności, danych, dokumentacji lub integracji. Dlatego czasami sama refaktoryzacja nie wystarczy.
Modernizację warto rozważyć wtedy, gdy istniejące rozwiązanie nadal realizuje potrzeby biznesowe, ale używana technologia, architektura lub zależności zaczynają istotnie zwiększać koszt dalszego rozwoju.
Rewrite może mieć sens wtedy, gdy obecna architektura fundamentalnie nie odpowiada potrzebom biznesowym, duża część rozwiązania wymagałaby przebudowy albo dalsza modernizacja staje się nieproporcjonalnie kosztowna. Decyzja powinna jednak wynikać z analizy, ponieważ napisanie systemu od nowa również wiąże się z istotnym ryzykiem.
Software developer może identyfikować problemy w kodzie i architekturze, przeprowadzać refaktoryzację, aktualizować zależności, tworzyć testy, wykonywać code review oraz proponować rozwiązania ograniczające powstawanie kolejnego długu technicznego.
Tak. Przejęcie istniejącego projektu powinno rozpocząć się od poznania kodu, architektury, infrastruktury, integracji, dokumentacji oraz kluczowych procesów biznesowych. Następnie można określić ryzyka i przygotować plan dalszego utrzymania, refaktoryzacji lub modernizacji systemu.
Może go zwiększać, ponieważ każda nowa funkcja musi uwzględniać istniejące ograniczenia i zależności. Jeżeli dodatkowo brakuje testów albo dokumentacji, większa część czasu może być potrzebna na analizę, testowanie i zabezpieczanie istniejących procesów.
Najważniejsze działania to regularne aktualizacje, refaktoryzacja, code review, automatyczne testy, dokumentowanie istotnych decyzji, kontrolowanie zależności, utrzymywanie backlogu technicznego oraz przeznaczanie części czasu developmentu na utrzymanie jakości istniejącego systemu.
Tak, jeśli ograniczenia systemu powodują, że wdrażanie nowych produktów, kanałów sprzedaży, integracji lub procesów staje się zbyt kosztowne albo zbyt ryzykowne. Wtedy problem techniczny zaczyna wpływać bezpośrednio na decyzje biznesowe.
Ten wpis stworzył
Ekspert od wycen dedykowanych rozwiązań i zarządzania projektami. Posiada ogromne doświadczenie w tworzeniu ofert idealnie dopasowanych do potrzeb i oczekiwań klientów, specjalista łączący pasję do nowych wyzwań z analitycznym podejściem do każdego szczegółu projektu.
Sprawdź, jak wybrać firmę programistyczną do rozwoju strony WordPress, sklepu WooCommerce, systemu B2B lub aplikacji webowej. Zobacz, o co zapytać przed współpracą.
Sprawdź, jak wygląda współpraca z software house – od analizy po wdrożenie i rozwój. Poznaj proces krok po kroku i uniknij kosztownych błędów.
Jak przeprowadzić testy akceptacyjne strony internetowej? Sprawdź UAT, kryteria akceptacji, checklistę przed publikacją i protokół odbioru strony.
Masz projekt w Figmie i chcesz wdrożyć go do WordPress? Sprawdź, jak przygotować Figma, RWD, CMS i funkcje oraz jakich błędów uniknąć przy wdrożeniu.
Share:
