{"id":21671,"date":"2020-10-29T17:07:54","date_gmt":"2020-10-29T16:07:54","guid":{"rendered":"https:\/\/altkomsoftware.com\/jak-zarzadzac-dlugiem-technologicznym-za-pomoca-analizy-kodu\/"},"modified":"2025-04-01T10:53:03","modified_gmt":"2025-04-01T08:53:03","slug":"jak-zarzadzac-dlugiem-technologicznym-za-pomoca-analizy-kodu","status":"publish","type":"post","link":"https:\/\/stg.altkomsoftware.com\/pl\/blog\/jak-zarzadzac-dlugiem-technologicznym-za-pomoca-analizy-kodu\/","title":{"rendered":"Jak inteligentnie zarz\u0105dza\u0107 d\u0142ugiem technologicznym za pomoc\u0105 behawioralnej analizy kodu?"},"content":{"rendered":"

Czym jest d\u0142ug technologiczny? Najlepsze wyja\u015bnienie tego terminu, ukutego przez Warda Cunninghama, dostarczy\u0142 Marin Fowler<\/a>. Nie potrafimy perfekcyjnie rozwija\u0107 system\u00f3w informatycznych. Ka\u017cda dodana lub zmodyfikowana funkcjonalno\u015b\u0107 wprowadza niewielkie braki w jako\u015bci oprogramowania. Te braki kumuluj\u0105 si\u0119 z czasem i utrudniaj\u0105 nam utrzymanie tempa, w jakim dostarczamy nasze systemy na produkcj\u0119.<\/p>\n

We\u017amy pod uwag\u0119 system z d\u0142ugiem technologicznym. Bez d\u0142ugu, wdro\u017cenie danej funkcjonalno\u015bci zaj\u0119\u0142oby nam 4 dni, z powodu zad\u0142u\u017cenia – 6 dni. Oznacza to, \u017ce te dodatkowe 2 dni to odsetki, kt\u00f3re musimy zap\u0142aci\u0107. Je\u015bli czas potrzebny na napraw\u0119 kodu i usuni\u0119cie d\u0142ugu technologicznego wynosi 3 dni, to ca\u0142a zmiana zajmie nam 7 dni i usuni\u0119cie d\u0142ugu nie jest op\u0142acalne. Je\u015bli jednak wiemy, \u017ce nie jest to jedyna zmiana, jak\u0105 musimy wprowadzi\u0107 w danym elemencie oprogramowania, to sp\u0119dzenie tych dodatkowych 3 dni szybko si\u0119 zwr\u00f3ci. Nale\u017cy te\u017c pami\u0119ta\u0107, \u017ce d\u0142ug technologiczny ma tendencj\u0119 do kumulowania si\u0119. Przysz\u0142e zmiany w komponencie z d\u0142ugiem spowoduj\u0105 tylko jego wzrost, a czas potrzebny na rozw\u00f3j nowych funkcji wzro\u015bnie z 6 do 10 lub 15 dni.<\/p>\n

Jakie s\u0105 przyczyny powstawania d\u0142ugu technologicznego? We\u017amy pod uwag\u0119 prawa Lehmana<\/a> dotycz\u0105ce ewolucji oprogramowania:<\/p>\n

Prawo ci\u0105g\u0142ych zmian<\/strong><\/p>\n

\u201cSystem musi by\u0107 stale dostosowywany lub staje si\u0119 stopniowo mniej u\u017cyteczny\u201d\u200b<\/p><\/blockquote>\n

Prawo o rosn\u0105cej z\u0142o\u017cono\u015bci\u200b<\/strong><\/p>\n

\u201cW miar\u0119 jak system ewoluuje, jego z\u0142o\u017cono\u015b\u0107 ro\u015bnie, chyba \u017ce prowadzone s\u0105 prace maj\u0105ce na celu jego utrzymanie lub ograniczenie tego trendu.\u201d\u200b<\/p><\/blockquote>\n

Z jednej strony, musimy dodawa\u0107 nowe funkcje, modyfikowa\u0107 istniej\u0105ce, aby system pozosta\u0142 aktualny i u\u017cyteczny. Z drugiej strony, nasze prace nad rozwojem systemu zwi\u0119kszaj\u0105 jego z\u0142o\u017cono\u015b\u0107 i je\u015bli nie podejmiemy odpowiednich dzia\u0142a\u0144 naprawczych, z\u0142o\u017cono\u015b\u0107 ta ostatecznie uniemo\u017cliwi ewolucj\u0119 systemu z powodu rosn\u0105cych op\u00f3\u017anie\u0144 i nadmiernych koszt\u00f3w. Jak wszyscy wiemy, rozw\u00f3j oprogramowania jest do\u015bwiadczeniem edukacyjnym. Oznacza to, \u017ce rozpoczynaj\u0105c nowy projekt posiadamy bardzo ma\u0142\u0105 wiedz\u0119 na temat rzeczywistego problemu, kt\u00f3ry staramy si\u0119 rozwi\u0105za\u0107 oraz dziedziny biznesu, w kt\u00f3rej pracujemy. Uczymy si\u0119 po drodze i za\u0142o\u017cenia oraz rozwi\u0105zania architektoniczne, kt\u00f3re przyjeli\u015bmy na pocz\u0105tku projektu, szybko staj\u0105 si\u0119 nieaktualne. Zmieniaj\u0105 si\u0119 wymagania biznesowe, zbli\u017caj\u0105 si\u0119 terminy. Cz\u0119sto po\u015bwi\u0119camy jako\u015b\u0107, aby jak najszybciej wprowadzi\u0107 kod na produkcj\u0119. R\u00f3wnie\u017c dob\u00f3r technologii nierzadko nie jest optymalny i oparty na \u201enowych\u201d trendach, a nie na dopasowaniu danej technologii do prowadzonego przez nas projektu. Wszystkie te i wiele innych czynnik\u00f3w powoduj\u0105 powstanie d\u0142ugu technologicznego
\n<\/a><\/p>\n

Zarz\u0105dzanie d\u0142ugiem technologicznym<\/span><\/h2>\n

Jak mo\u017cemy poradzi\u0107 sobie z d\u0142ugiem technologicznym? Moim zdaniem, istniej\u0105 trzy kluczowe elementy, o kt\u00f3re musimy zadba\u0107, je\u015bli nie chcemy aby nasz projekt zbankrutowa\u0142: architektura systemu, zesp\u00f3\u0142 i organizacja procesu. Jak wiemy z prawa Conway’a<\/a> (a raczej z jego konsekwencji) – wszystkie one musz\u0105 dzia\u0142a\u0107 razem, w przeciwnym razie jeste\u015bmy skazani na pora\u017ck\u0119.<\/p>\n

Architektura systemu na ka\u017cdym poziomie, od podzia\u0142u na komponenty\/modu\u0142y po wewn\u0119trzn\u0105 struktur\u0119 pakiet\u00f3w i klasy powinny oddziela\u0107 rzeczy, kt\u00f3re maj\u0105 r\u00f3\u017cne powody do zmiany lub zmianiaj\u0105 si\u0119 w r\u00f3\u017cnym tempie. Jak zobaczymy w trakcie lektury tego postu, jest to niezwykle istotne. Mieszanie r\u00f3\u017cnych obowi\u0105zk\u00f3w w tym samym komponencie zwi\u0119ksza prawdopodobie\u0144stwo wyst\u0105pienia wad i dodatkowo wzmacnia trend spadku jako\u015bci.
\nArchitektura musi by\u0107 r\u00f3wnie\u017c kompatybilna z organizacj\u0105 zespo\u0142\u00f3w, aby zminimalizowa\u0107 straty zwi\u0105zane z dodatkow\u0105 komunikacj\u0105 i koordynacj\u0105 oraz wyeliminowa\u0107 kosztowne \u0142\u0105czenie kodu z wielu ga\u0142\u0119zi rozwojowych.<\/p>\n

Nie jeste\u015bmy w stanie stworzy\u0107 „idealnej” architektury i organizacji, kt\u00f3ra b\u0119dzie odpowiednia przez ca\u0142y cykl \u017cycia projektu. Oznacza to, \u017ce musimy stale monitorowa\u0107 stan naszej architektury, jako\u015b\u0107 kodu, wzorce komunikacji, organizacj\u0119 zespo\u0142u, aby w\u0142a\u015bciwie reagowa\u0107 i planowa\u0107 usprawnienia w obszarach, w kt\u00f3rych przynosi to najwi\u0119ksze korzy\u015bci.<\/p>\n

Wielu mened\u017cer\u00f3w ignoruje potrzeb\u0119 takich dzia\u0142a\u0144. Maj\u0105 tendencj\u0119 do obwiniania zespo\u0142\u00f3w programistycznych za braki w jako\u015bci oraz kwestionowania ich umiej\u0119tno\u015bci i zaanga\u017cowania. Nie jest to oczywi\u015bcie prawd\u0105. Akumulacja d\u0142ugu technologicznego jest naturalnym procesem i wszyscy uczestnicy projektu s\u0105 cz\u0119\u015bciowo za ni\u0105 odpowiedzialni.<\/p>\n

W\u0142a\u015bciwy monitoring, ewolucja architektury systemu oraz organizacja zespo\u0142u s\u0105 szczeg\u00f3lnie wa\u017cne w projektach wykorzystuj\u0105cych metodyki agile. W takich projektach staramy si\u0119 doprowadzi\u0107 nasz kod do produkcji tak szybko, jak to mo\u017cliwe. Cz\u0119sto zespo\u0142y zapominaj\u0105, \u017ce nale\u017cy to robi\u0107 bez po\u015bwi\u0119cania jako\u015bci kodu. W miar\u0119 jak przechodzimy do produkcji, nasz kod jest obecnie poddawany konserwacji, a jak pokazuj\u0105 ostatnie badania naukowe, 40 do 80% koszt\u00f3w projektu informatycznego jest wydawane na utrzymanie oprogramowania. Brak dzia\u0142ania w przypadku zwi\u0119kszonej z\u0142o\u017cono\u015bci systemu ma konsekwencje dla wszystkich zainteresowanych stron projektu. Dla kierownictwa oznacza to niedotrzymanie termin\u00f3w, wyd\u0142u\u017cenie czasu realizacji, brak przewidywalno\u015bci procesu rozwoju. Dla u\u017cytkownik\u00f3w oznacza to wiele b\u0142\u0119d\u00f3w, kt\u00f3re sprawiaj\u0105, \u017ce ich codzienna praca jest ci\u0119\u017csza i frustruj\u0105ca, obni\u017caj\u0105c efektywno\u015b\u0107 biznesow\u0105. Dla ca\u0142ej organizacji oznacza to dodatkowe koszty i utrat\u0119 przewagi konkurencyjnej.<\/p>\n

Istnieje wiele narz\u0119dzi i technik, kt\u00f3rych obecnie u\u017cywa wi\u0119kszo\u015b\u0107 organizacji do walki z d\u0142ugiem technicznym. Wymie\u0144my te najpopularniejsze i ich braki:<\/p>\n