{"id":21738,"date":"2021-01-21T12:12:12","date_gmt":"2021-01-21T11:12:12","guid":{"rendered":"https:\/\/altkomsoftware.com\/dlug-technologiczny-chytry-dwa-razy-traci\/"},"modified":"2025-04-01T10:53:04","modified_gmt":"2025-04-01T08:53:04","slug":"dlug-technologiczny-chytry-dwa-razy-traci","status":"publish","type":"post","link":"https:\/\/stg.altkomsoftware.com\/pl\/blog\/dlug-technologiczny-chytry-dwa-razy-traci\/","title":{"rendered":"D\u0142ug technologiczny: chytry dwa razy traci"},"content":{"rendered":"

Przy systemach legacy cz\u0119sto, je\u015bli nie zawsze, spotykamy si\u0119 z poj\u0119ciem „d\u0142ug technologiczny”. Najpro\u015bciej m\u00f3wi\u0105c, oznacza on nagromadzenie wielu zr\u00f3\u017cnicowanych problem\u00f3w technicznych, kt\u00f3re powstaj\u0105 podczas praktycznie ka\u017cdego projektu informatycznego.<\/strong> Ignorowanie ich wp\u0142ywa na jako\u015b\u0107 i tempo realizacji przedsi\u0119wzi\u0119cia. To jak rata kredytu, kt\u00f3ra\u00a0systematycznie niesp\u0142acana, z czasem generuje niebotyczne odsetki, kt\u00f3re mog\u0105\u00a0doprowadzi\u0107 nas do bankructwa.<\/p>\n

Bezlitosny d\u0142ug technologiczny<\/h2>\n

Nara\u017ca on nas na podatno\u015bci bezpiecze\u0144stwa, ogranicza mo\u017cliwo\u015bci dalszego rozwoju oraz zwi\u0119ksza koszty z tym zwi\u0105zane. Oprogramowanie oparte o starsze technologie stwarza ryzyko pojawienia si\u0119 luk bezpiecze\u0144stwa. Wszyscy wiemy, \u017ce lepiej zapobiega\u0107 ni\u017c leczy\u0107. Profilaktyka zwi\u0105zana z d\u0142ugiem technologicznym obni\u017cy koszty rozwoju, a mo\u017ce u\u0142atwi\u0107 r\u00f3wnie\u017c ewentualn\u0105 migracj\u0119 do chmury, kt\u00f3ra nabiera w obecnym czasie coraz wi\u0119kszego znaczenia. Nie warto by\u0107 m\u0105drym po szkodzie.<\/p>\n

D\u0142ug technologiczny mo\u017ce zacz\u0105\u0107 narasta\u0107 ju\u017c na etapie powstawania projektu. Ka\u017cdy dodatkowy rozw\u00f3j jest obarczony dodatkowym ryzykiem jego wygenerowania, zw\u0142aszcza gdy idziemy \u201ena skr\u00f3ty\u201d: minimalizuj\u0105c jednostkowe koszty b\u0105d\u017a zmiany realizowane s\u0105 przez zesp\u00f3\u0142 niedo\u015bwiadczony lub s\u0142abo znaj\u0105cy rozwi\u0105zanie. Na d\u0142ug technologiczny warto r\u00f3wnie\u017c spojrze\u0107 z punktu widzenia starzenia si\u0119 aplikacji. Zmienia si\u0119 otoczenie, powstaj\u0105 nowe frameworki, u\u017cyte biblioteki staj\u0105 si\u0119 przestarza\u0142e, powstaj\u0105 ich nowe wersje, a w poprzednich wykrywane s\u0105 takie czy inne podatno\u015bci. Z czasem r\u00f3wnie\u017c zastosowana architektura aplikacji zaczyna by\u0107 ci\u0119\u017carem.<\/p>\n

Od mono do mikro<\/h2>\n

Jeszcze niedawno budowali\u015bmy du\u017ce, monolityczne aplikacje. Dzi\u015b zmierzamy w stron\u0119 mikroserwis\u00f3w i rozwi\u0105za\u0144 przystosowanych do uruchomiania w \u015brodowiskach kontenerowych czy chmurowych. Dzisiaj sytuacja zmusi\u0142a nas do ograniczenia kontakt\u00f3w mi\u0119dzyludzkich. To z kolei wp\u0142ywa na wi\u0119ksze u\u017cycie kana\u0142\u00f3w zdalnych. Aplikacje legacy cz\u0119sto nie s\u0105 na to przygotowane.<\/p>\n

Niezale\u017cnie od \u017ar\u00f3d\u0142a stajemy przed nag\u0142\u0105 konieczno\u015bci\u0105 modyfikacji systemu. Je\u017celi jeste\u015bmy obarczeni du\u017cym d\u0142ugiem technologicznym, ewentualne zmiany i rozw\u00f3j mog\u0105 stanowi\u0107 istotny problem. Nale\u017cy zdawa\u0107 sobie z tego spraw\u0119, gdy\u017c wtedy istnieje nadzieja, \u017ce b\u0119dziemy mogli sobie z tym poradzi\u0107.<\/p>\n

Sp\u0142acaj d\u0142ug technologiczny i rozwijaj system<\/h2>\n

Bardzo cz\u0119sto w biznesie, czy nawet zespo\u0142ach IT, istnieje pogl\u0105d, \u017ce likwidacja d\u0142ugu nie wnosi w zasadzie wi\u0119kszej korzy\u015bci biznesowej. Racja, jest to typowy zabieg technologiczny, czysta profilaktyka. W zwi\u0105zku z tym organizacje maj\u0105 bardzo du\u017ce opory, aby po\u015bwi\u0119ci\u0107 czas czy wydatkowa\u0107 bud\u017cet na systematyczne pozbywanie si\u0119 tych zaleg\u0142o\u015bci. Niestety, takie podej\u015bcie powoduje, \u017ce z ka\u017cdym rokiem przysz\u0142e koszty likwidacji tego zad\u0142u\u017cenia b\u0119d\u0105 ros\u0142y. W tym wypadku nie warto m\u0105drze\u0107 dopiero po szkodzie.<\/p>\n

Z naszych dotychczasowych obserwacji wynika, \u017ce mimo wszystko pozbywaj\u0105c si\u0119 na bie\u017c\u0105co d\u0142ugu technologicznego, zapewniamy sobie mo\u017cliwo\u015b\u0107 dalszego rozwoju systemu, ale przede wszystkim mo\u017cliwo\u015b\u0107 znacznego ograniczenia kosztu, czy mo\u017ce bardziej ograniczenia ryzyka powstania znacznego kosztu w najmniej spodziewanym momencie. Ka\u017cde oprogramowanie, je\u015bli przestanie by\u0107 wspierane, b\u0119dzie starza\u0142o si\u0119 szybko. Systemy nierozwijane maj\u0105 tendencj\u0119 zar\u00f3wno do narastania d\u0142ugu jak i do utraty warto\u015bci biznesowej. W takiej sytuacji pr\u0119dzej czy p\u00f3\u017aniej migracja do nowego systemu staje si\u0119 przede wszystkim nieuchronna.<\/p>\n

Staro\u015b\u0107 (nie) rado\u015b\u0107<\/h2>\n

Musimy mie\u0107 \u015bwiadomo\u015b\u0107, \u017ce ka\u017cdy system si\u0119 starzeje.\u00a0\u00a0Je\u015bli tylko mamy wp\u0142yw na to, \u017ceby reagowa\u0107 i minimalizowa\u0107 szkody, to po prostu r\u00f3bmy – tak naprawd\u0119 nie ma jednego prostego podej\u015bcia do legacy. Nie ma \u017cadnego antidotum – ka\u017cdy system jest inny: b\u0119dzie te\u017c r\u00f3\u017cni\u0142 si\u0119 architektur\u0105, technologi\u0105 i wiekiem. Nale\u017cy wykona\u0107 du\u017c\u0105 prac\u0119 zwi\u0105zan\u0105 z analiz\u0105<\/a>, ewentualnie zatrudni\u0107 firm\u0119, kt\u00f3ra wykona prace za nas.<\/p>\n

Co mo\u017ce sygnalizowa\u0107 problemy?<\/p>\n