Pracuj\u0119 z firmami, kt\u00f3re maj\u0105 aplikacje dzia\u0142aj\u0105ce od lat. Kod dzia\u0142a, serwery chodz\u0105, klienci nie narzekaj\u0105. A jednak \u2013 ka\u017cda nowa funkcja zajmuje coraz wi\u0119cej czasu, a zesp\u00f3\u0142 jest wiecznie zestresowany. To klasyczny objaw d\u0142ugu technologicznego, kt\u00f3ry nie zawsze wida\u0107 na pierwszy rzut oka. Dzi\u015b poka\u017c\u0119 Ci 3 sygna\u0142y, kt\u00f3re \u015bwiadcz\u0105 o tym, \u017ce Tw\u00f3j d\u0142ug technologiczny wymkn\u0105\u0142 si\u0119 spod kontroli.<\/p>\n
Je\u015bli wdro\u017cenie prostej zmiany \u2013 jak dodanie nowego pola w formularzu \u2013 anga\u017cuje po\u0142ow\u0119 zespo\u0142u na dwa dni, masz problem. W dobrze utrzymanej aplikacji taka modyfikacja to godzina pracy. Gdy kod jest spl\u0105tany, brakuje test\u00f3w, a zale\u017cno\u015bci s\u0105 niejasne, ka\u017cda edycja rodzi ryzyko popsucia czego\u015b innego.<\/p>\n
Przyk\u0142ad z \u017cycia:<\/strong> Firma e-commerce mia\u0142a system koszyka zakupowego, kt\u00f3ry nie by\u0142 refactorowany od 3 lat. Dodanie nowej metody p\u0142atno\u015bci wymaga\u0142o r\u0119cznej zmiany w 12 plikach, bo logika by\u0142a rozsmarowana po ca\u0142ej aplikacji. Projekty przeze mnie audytowane cz\u0119sto ujawniaj\u0105, \u017ce a\u017c 40% czasu programist\u00f3w idzie na walk\u0119 z istniej\u0105cym kodem, a nie na nowe funkcje.<\/p>\n Co robi\u0107?<\/strong> Regularnie mierz czas wdro\u017cenia \u015bredniej wielko\u015bci taska. Je\u015bli ro\u015bnie z miesi\u0105ca na miesi\u0105c \u2013 to alarm. Wdr\u00f3\u017c code review i automatyzacj\u0119 test\u00f3w, by odzyska\u0107 kontrol\u0119.<\/p>\n Ka\u017cda firma zak\u0142ada okres wdro\u017cenia nowego developera. Ale je\u015bli trwa on d\u0142u\u017cej ni\u017c 2-3 miesi\u0105ce, a nowa osoba wci\u0105\u017c boi si\u0119 dotkn\u0105\u0107 istniej\u0105cego kodu \u2013 co\u015b jest nie tak. D\u0142ug technologiczny objawia si\u0119 te\u017c s\u0142ab\u0105 dokumentacj\u0105, brakiem standard\u00f3w i architektur\u0105, kt\u00f3r\u0105 tylko \u201estarzy\u201d rozumiej\u0105.<\/p>\n Dlaczego to boli?<\/strong> Bo rotacja w IT jest faktem. Gdy jedyny znawca legacy kodu odchodzi, firma staje przed widmem przepisania ca\u0142ego systemu. Widzia\u0142em startup, kt\u00f3ry straci\u0142 kluczowego developera i przez p\u00f3\u0142 roku nie by\u0142 w stanie wypu\u015bci\u0107 \u017cadnej aktualizacji. Kosztowa\u0142 ich to utrat\u0119 g\u0142\u00f3wnego klienta.<\/p>\n Jak to odkr\u0119ci\u0107?<\/strong> Wprowad\u017a onboarding checklist, pisz dokumentacj\u0119 \u201elive\u201d (komentarze w kodzie i README), a przede wszystkim stopniowo refactoruj najbardziej zagmatwane fragmenty. Nie musisz przepisywa\u0107 wszystkiego \u2013 zacznij od obszar\u00f3w, kt\u00f3re zmieniasz najcz\u0119\u015bciej.<\/p>\n Z pozoru paradoks: im wi\u0119cej testujesz i poprawiasz, tym wi\u0119cej b\u0142\u0119d\u00f3w. W praktyce oznacza to, \u017ce Twoja baza kodu jest tak niestabilna, \u017ce ka\u017cda poprawka generuje dwa nowe problemy. To klasyczny d\u0142ug technologiczny w czystej postaci \u2013 zaniechania z przesz\u0142o\u015bci odbijaj\u0105 si\u0119 czkawk\u0105.<\/p>\n Statystyka, kt\u00f3r\u0105 warto zna\u0107:<\/strong> Wed\u0142ug bada\u0144 Stripe, developerzy sp\u0119dzaj\u0105 \u015brednio 17 godzin tygodniowo na utrzymaniu istniej\u0105cego kodu, zamiast tworzy\u0107 now\u0105 warto\u015b\u0107. W firmach z wysokim d\u0142ugiem technologicznym ten czas ro\u015bnie do 25+ godzin. To prawie 3 pe\u0142ne dni robocze stracone na gaszenie po\u017car\u00f3w.<\/p>\n Przyk\u0142ad:<\/strong> Aplikacja SaaS do zarz\u0105dzania projektami mia\u0142a b\u0142\u0105d w synchronizacji danych. Zesp\u00f3\u0142 \u0142ata\u0142 go 4 razy w ci\u0105gu roku, ale nigdy nie usun\u0105\u0142 pierwotnej przyczyny \u2013 z\u0142ego projektu bazy danych. Ostatecznie musieli przepisa\u0107 warstw\u0119 danych, co zaj\u0119\u0142o 3 miesi\u0105ce i kosztowa\u0142o 150 000 z\u0142.<\/p>\n Co robi\u0107?<\/strong> Zacznij \u015bledzi\u0107 metryk\u0119 MTTR (Mean Time to Resolve). Je\u015bli ro\u015bnie, a cz\u0119stotliwo\u015b\u0107 b\u0142\u0119d\u00f3w te\u017c \u2013 to sygna\u0142, \u017ce potrzebujesz audytu architektury. Nie czekaj, a\u017c jeden b\u0142\u0105d zatrzyma ca\u0142\u0105 firm\u0119.<\/p>\n D\u0142ug technologiczny to nie abstrakcyjne poj\u0119cie z wyk\u0142ad\u00f3w \u2013 to realne pieni\u0105dze i czas, kt\u00f3re uciekaj\u0105 przez palce. Trzy opisane sygna\u0142y: heroiczne zmiany, d\u0142ugi onboarding i rosn\u0105ce b\u0142\u0119dy, to czerwone flagi, kt\u00f3re powiniene\u015b traktowa\u0107 powa\u017cnie. W JurskiTech.pl regularnie pomagamy firmom przeprowadza\u0107 audyty kodu i wdra\u017ca\u0107 strategie redukcji d\u0142ugu, odzyskuj\u0105c kontrol\u0119 nad rozwojem aplikacji. Pami\u0119taj: kod, kt\u00f3ry dzia\u0142a dzisiaj, mo\u017ce by\u0107 kul\u0105 u nogi jutro. Zajmij si\u0119 nim, zanim b\u0119dzie za p\u00f3\u017ano.<\/p>\n","protected":false},"excerpt":{"rendered":" Czy Tw\u00f3j zesp\u00f3\u0142 programistyczny ma ukryty d\u0142ug technologiczny? 3 sygna\u0142y Pracuj\u0119 z firmami, kt\u00f3re maj\u0105 aplikacje dzia\u0142aj\u0105ce od lat. Kod dzia\u0142a, serwery chodz\u0105, klienci nie narzekaj\u0105. A jednak \u2013 ka\u017cda nowa funkcja zajmuje coraz wi\u0119cej czasu, a zesp\u00f3\u0142 jest wiecznie zestresowany. To klasyczny objaw d\u0142ugu technologicznego, kt\u00f3ry nie zawsze wida\u0107 na pierwszy rzut oka. Dzi\u015b<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[704,904,937,560],"class_list":["post-2447","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-audyt-kodu","tag-dlug-technologiczny","tag-technical-debt","tag-utrzymanie-aplikacji"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2447","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=2447"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2447\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2447"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2447"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2447"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}2. Nowi programi\u015bci potrzebuj\u0105 miesi\u0119cy, by sta\u0107 si\u0119 produktywni<\/h3>\n
3. Liczba b\u0142\u0119d\u00f3w produkcyjnych ro\u015bnie, a nie maleje<\/h3>\n
Podsumowanie<\/h3>\n