Kierunki rozwoju software developmentu

Krzysztof Kempiński
Mar 22 · 15 min read

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Adamem Lejmanem o kierunkach rozwoju software developmentu.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

https://porozmawiajmyoit.pl/poit-107-kierunki-rozwoju-software-developmentu/

Cześć! Mój dzisiejszy gość to CEO Altkom Software & Consulting wykładowca akademicki na Politechnice Warszawskiej, programista Javy i pierwszy w Polsce certyfikowany trener Javy.

Do 2006 roku zajmował stanowisko dyrektora w dziale Enterprise Risk Services Deloitte, odpowiadał za projekty realizowane dla sektora bankowego. Od marca 2006 roku nieprzerwanie na czele software house’u Altkom Software & Consulting , najpierw w roli dyrektora operacyjnego, obecnie prezesa zarządu.

Od 2019 zarządza również spółką Altkom Experts, zajmującą się outsourcingiem specjalistów i zespołów IT.

Moim i Waszym gościem jest dzisiaj Adam Lejman.

Cześć, Adam! Bardzo mi miło gościć cię w podcaście.

Cześć, Krzysztof! Jest mi również niezmiernie miło, że możemy dziś porozmawiać.

Mój plan na tę rozmowę to wyciągnąć z Adama jego doświadczenie w branży i porozmawiać o kierunkach rozwoju software developmentu, także cieszę się niezmiernie!

Zapytam standardowo: czy słuchasz podcastów, jeśli tak, to może masz swoje ulubione audycje?

Oczywiście, słucham — uważam, że podcasty to znakomita forma rozwoju i dowiedzenia się co się dzieje na rynku, przy czym ostatnio tak właśnie stwierdziłem, że chyba najwięcej słucham podcastów związanych z zarządzaniem i ciekawymi osobami, które osiągnęły coś w biznesie, więc takie moje ulubione podcasty z ostatnich miesięcy to na pewno podcast Macieja Witkowskiego Zaprojektuj swoje życie czy też dużo słuchałem Mariusz Chrapko Menedżer Plus, ale również te podcasty stricte IT.

Twój podcast jest jednym z moich ulubionych, także polecam wszystkim do słuchania, szczególnie w czasach dojeżdżania do pracy czy długich podróży. Znakomita forma, żeby się rozwijać.

Super. Dzięki wielkie za polecenie!

Tak jak mówiłem na początku, masz ponad 25 komercyjnego doświadczenia w tworzeniu oprogramowania dla małych, dla dużych firm. Może nawet częściej dla tych większych przedsiębiorstw. Czy według ciebie patrząc z perspektywy tego czasu jest sens mówienia o kierunkach rozwoju software developmentu? Czy w tak szybko rozwijającej się, prężnej branży silenie się na jakieś predykcje co do przyszłości ma w ogóle sens?

Z jednej strony branża się rozwija, a z drugiej strony mam takie poczucie, że potrzeba tworzenia programowania od zawsze była i dając się perspektywie, na którą mamy wpływ, ona zawsze będzie.

Chyba mniej więcej 20 lat temu jeden z szefów IT dużego telekoma powiedział mi „Adam, kończy się software na zamówienie, powinniście zmienić profil na firmę wdrożeniową”. Odpowiedziałem: „Moim zdaniem zawsze będzie potrzeba budowania zindywidualizowanych rozwiązań” i z perspektywy czasu widać, że ta potrzeba jest i ona nie zanika, wręcz rośnie, więc oczywiście moim zdaniem cały czas software house’y mają rację bytu na rynku i patrząc na to ile software house’ów mamy w Polsce, to idzie już prawie w kilkaset podmiotów, które dzisiaj aktywnie działają na rynku polskim.

Z drugiej strony moim zdaniem nie ma sensu silić się na jakieś długoterminowe przewidywania, w jakich kierunkach to się będzie rozwijało, bo mam takie wrażenie, że rynek polski mimo tego, że bardzo jest na bieżąco z narzędziami, które są stosowane, to jednak z perspektywy polskich klientów obserwuję, że pewne trendy, które gdzieś się wydarzają na zachodzie, do nas trafiają z pewnym opóźnieniem. Wystarczy śledzić to, co się dzieje na rynkach dojrzalszych, bardziej rozwiniętych, chętnie adaptujących nowe rozwiązania i do nas, do Polski to w ciągu 2–3 lat przyjdzie.

Trochę zgodnie z powiedzeniem, że przyszłość już się wydarzyła, tylko jest nierównomiernie rozdystrybuowana. Wystarczy patrzeć gdzie ta przyszłość jest dalej w stosunku do naszego regionu i wystarczy patrzeć, co tam się dzieje, jakie frameworki, jakie narzędzia, jakie architektury, jakie paradygmaty są stosowane i pod to się przygotowywać. Wtedy na pewno będziemy w stanie skutecznie oferować naszym klientom to, czego oczekują.

Trochę zgodnie z powiedzeniem, że przyszłość już się wydarzyła, tylko jest nierównomiernie rozdystrybuowana. Wystarczy patrzeć gdzie ta przyszłość jest dalej w stosunku do naszego regionu i wystarczy patrzeć, co tam się dzieje, jakie frameworki, jakie narzędzia, jakie architektury, jakie paradygmaty są stosowane i pod to się przygotowywać.

Okej, to zanim zaczniemy rozmawiać o przyszłości, o tym, co może za chwilę do nas zapuka, to zastanówmy się chwilkę nad tym, gdzie obecnie jesteśmy. Chciałbym wyjść od takiego pytania związanego z rozwiązaniami korporacyjnymi, właściwie z architekturami tych rozwiązań. Bo z jednej strony tak jak obserwuję sobie zwłaszcza to, co się dzieje w takim trochę posta pandemicznym świecie, to taka tendencja do bycia agile, bycia zwinnym, ale z drugiej strony jednak ta druga strona mocno stoi w chęci stabilności, jeśli chodzi o korporacje.

Teraz przyjrzyjmy się tym architekturom wykorzystywanym w tych rozwiązaniach. Czy one są w Twojej opinii mocno stabilne i trochę z tyłu, za szybkim postępem? W którym kierunku się rozwijają? Z jakimi problemami obecnie te architektury się w ogóle mierzą?

Myślę, że to bardzo różni się od rynku, z jakim się pracuje. My akurat pracujemy w dużej mierze z sektorem finansowym, który z jednej strony jest dosyć aktywny, jeżeli chodzi o adopcję nowych rozwiązań, ale ponieważ tu są żywe korporacje, to te nowinki trochę dłużej się przebijają w szczególności do tych dużych rozwiązań — mają trochę dłuższą drogę.

To, co na pewno dzisiaj wyraźnie szykuje się jako taki trend uwzględnienia w architekturach w dużych przedsiębiorstwach, to jest kilka paradygmatów, które należy uwzględnić. Z jednej strony robiąc rozwiązania dla dużych korporacji zawsze to rozwiązanie jest elementem jakiegoś większego ekosystemu.

Nie mam na myśli ekosystemu danego przedsiębiorstwa, gdzie często mamy do czynienia z potrzebą integracji z kilkunastoma czy wręcz kilkudziesięcioma różnymi systemami, ale to jest też kwestia, że duże przedsiębiorstwa coraz bardziej chcą i muszą się otwierać na swoich partnerów, dostawców, klientów z perspektywy właśnie różnego rodzaju API do podmiotów zewnętrznych.

Czyli tak naprawdę produkując architekturę dla korporacji musimy uwzględnić również otoczenie tej korporacji. To znaczy — w jaki sposób dana firma wystawi interfejsy do swoich systemów, do partnerów. Czy mówimy o takich aspektach jak standard P2 w bankowości, dla płatności, czy mówimy o agregatorach ubezpieczeń, gdzie każde towarzystwo ubezpieczeniowe musi wystawić jakieś API do tego, żeby można było czytać ich produkty, cenić i w jakiś sposób to porównywać.

To jest na pewno taki ważny aspekt do uwzględnienia. Innym dosyć istotnym trendem, który od paru lat się zaznacza to jest kwestia dużych systemów korporacyjnych, które z jednej strony są drogie do wdrożenia i czasochłonne, a z drugiej strony wymagają też ciągłej aktualizacji.

My nazywamy to wewnętrznie pojęciem decaplingu starych systemów, to znaczy, że bardzo trudno jest korporacji wymienić system centralny, core’owy, taki główny jednorazowo i właściwie coraz mniej jest takich projektów, że dana firma decyduje się na wymianę swojego rozwiązania.

Tutaj wchodzi właśnie takie pojęcie rozłożenia głównego systemu na części, to znaczy zastanowienia się, które elementy z dużego systemu można w jakiś sposób zastąpić nowszymi elementami, jak wyciągnąć pewne procesy czy funkcjonalności, które wymagają szybkich aktualizacji na zewnątrz tego core’owego systemu i robić je w innych technologiach, w których możemy tę szybką zmienność zapewnić.

Cała koncepcja mikro serwisu wchodzi jako pewien element, który pozwala nam takie potrzeby realizować. Kwestia wdrażania różnych frameworków VPN-owych jest elementem, który pozwala takie duże systemy uelastycznić i nadać im nowy czas życia, ale też musimy cały czas pamiętać o tym, że jednym z kluczowych wyzwań w korporacjach, szczególnie jeżeli mamy wiele różnych systemów o różnym stanie życia, zbudowanych w różnych technologiach, to zapewnienie również ciągłości funkcjonowania procesów jest niezwykle ważne.

To, co się szczególnie ostatnio wydarzyło w czasach pandemicznych, gdzie wszyscy przeszli do online, to też percepcja użytkowników systemów jest taka, że właściwie każdy system powinien być cały czas dostępny. Teraz, jeżeli mamy podejście sprzed czasów pandemii, gdzie wdrożenie aktualizacji, rozwiązań trwały dwa razy w roku, raz na kwartał się wprowadziło i wtedy takie okna serwisowe wyłączały pewne dostępności, to właśnie dzisiaj jest to nieakceptowalne z perspektywy użytkowników, którzy siedząc z telefonem komórkowym właściwe w każdej chwili chce mieć dostęp do banku czy do informacji o swojej polisie czy swoim procesie, który przetwarzają z daną korporacją, więc zapewnienie ciągłości działania jest kolejnym aspektem, który też musimy uwzględniać i tutaj te wszystkie automatyzacje, które są związane z dostarczaniem poprawek są aspektem do uwzględnienia.

Tych zagadnień jest cała masa i w zależności do tego, z czym się mierzymy, to tych pomysłów i doświadczeń do wykorzystania jest też bardzo dużo, żeby zapewnić korporacjom dostarczenie wartości dla klientów na koniec dnia.

Tak, to jest na koniec dnia najistotniejsze. Powiedziałeś o mikroserwiach — to jest czy też była poradzenia sobie z wielkim monolitem z dużym couplingiem i z problemem rozwoju aplikacji, rozwoju oprogramowania na pewnym etapie.

Nie było pewnie w pewnym momencie żadnej konferencji, na której jakiegoś tematu związanego z mikro serwisami by nie było, stał się duży hype na mikroserwisy. Po jakimś czasie jako branża zauważyliśmy też pewne limity czy problemy wynikające ze stosowania mikroserwisów.

Mam wrażenie, że trochę mniej już się mówi o mikro serwisach jako takim złotym leku. Oczywiście tak jak to zawsze w software developmencie — są obszary zastosowania, gdzie mikroserwisy się świetnie sprawdzają, w innych niekoniecznie. Ale chciałbym cię zapytać, czy z tego co obserwujesz rynek, to mikroserwisy ciągle jeszcze są kierunkiem rozwoju, czymś co wyznacza trend, czy te może już okrzepłą technologią?

Trochę okrzepłą, w takim znaczeniu, ze się przyzwyczailiśmy, że to jest jedna z podstawowych architektur. Teraz nikt nie emocjonuje się tym, że będzie robił system w oparciu o mikroserwisy, bo to jest taki no-brainer. Po prostu tak się robi. Oczywiście mikroserwisy nie są rozwiązaniem na każde zło i ciągle jeszcze monolity czy takie modularne monolity też są w wielu przypadkach dobrym rozwiązaniem, bo jednak mikroserwisy są obarczone pewnym nakładem dodatkowej pracy czy też złożoności architektonicznej. Nie jest to więc lek na każde zło, aczkolwiek jest to dominujący trend, tym bardziej że biorąc pod uwagę coraz większą adopcję chmury również w Polsce, chociaż Polska jest trochę w tyle w porównaniu do świata zachodniego, ale widać znaczne przyspieszenie w ostatnim czasie.

Ten proces jest naturalnym elementem, który wykorzystuje cały potencjał chmury i tez wydaje mi się, że mając architekturę podzieloną na mikroserwisy dużo łatwiej jest poszczególnymi obszarami funkcjonalnymi, różnymi technologiami gospodarować. Bo jak możemy te architektury podzielić, no to w tym momencie też wchodzą w miejsca, gdzie nie trzeba budować rozwiązania od zera możliwości, skorzystania z platform low-code jako pewien element rozwiązania funkcjonalnego, czy też właśnie wykorzystywanie rozwiązań czy takich bardziej zaawansowanych typu server-less w jakimś obszarze, także mikroserwisy na pewno otworzyły wiele nowych możliwości, natomiast to nie jest tak, że teraz każdy system musimy zawsze robić mikroserwisów, bo wiadomo, że i nakład na pracę zespołu, zarządzanie zespołem tez jest dużo większy, chociaż ma to mnóstwo zalet, które warto wykorzystywać.

Jak obserwuję teraz to co się dzieje na rynku obserwując to, jakie firmy, jacy giganci technologiczni próbują wejść na rynek chmury, to myślę sobie, że chmura obliczeniowa i transformacja cyfrowa to jest coś takiego, co bardzo mocno zmieniło i zmienia software development.

Czy znajomość tych zagadnień związanych z cloud computingiem to jest według ciebie już coś takiego, co każdy programista praktycznie powinien gdzieś w swoim toolboxie mieć? Bo z jednej strony myślimy o chmurze jako o środowisku uruchomieniowym, jako o deploymencie apliakcji, ale jakby spojrzeć od strony architektury, to przecież to, że dana aplikacja będzie w chmurze może mieć wpływ na pewne decyzje architektoniczne, które podejmujemy — schodzimy dosyć blisko kodu.

Jak to więc jest — czy programiści będą ablo muszą obecnie być obeznani w chmurze? Czy to ciągle jest obszar, który jest kolejnym obszarem kierunku DevOpsowym, niekoniecznie programiści muszą sobie zdawać sprawę z tego, w jaki sposób aplikacje będą uruchamiane?

Oczywiście jest tak, że u programisty przede wszystkim liczy się umiejętność dobrego programowania i to jest kluczowe, szczególnie gdy mówimy o młodych osobach. Przede wszystkim musi być dobrym programistą — od tego zacznijmy. Natomiast oczywiście bez względu na to jakie umiejętności dana osoba posiada, to jednym z kluczowych aspektów tych umiejętności jest również rozpoznanie środowisk chmurowych i wzięcie pod uwagę tego, że tworzymy rozwiązanie, które będzie oparte o chmurę.

Absolutnie konieczne jest, żeby osoby, zajmujące się projektowaniem czy architekturą miały te kompetencje chmurowe rozwinięte i to jest element, który też widzę na rynku i u nas w firmie, który bardzo dynamicznie podlega rozwojowi, zadaniom edukacyjnym. Zdobywanie certyfikatów providerów chmurowych jest jak najbardziej w cenie i patrząc też na wycenę potem osób na rynku, to sooba, któr aposiada odpowiednie certyfikaty jest rozchwytywana dzisiaj przez rynek, więc absolutnie tak.

Natomiast też istotne jest to, żeby ciągle śledzić jak rozwijają się poszczególne usługi chmurowe, ponieważ to co obserwujemy, to co w środowiskach chmurowych się bardzo szybko zmienia i nawet rozwiązanie zrobione w chmurze rok temu dzisiaj może być bardzo optymalizowane pod kątem tego, jakie nowe usługi w chmurze się pojawiły u danego providera.

Warto nie zatrzymywać się i zdobycie jednego czy drugiego certyfikatu u danego providera nie kończy naszej ścieżki chmurowej, tylko trzeba cały czas to zaktualizować.

Przede wszystkim z perspektywy programisty, taki kierunek, który wydaje się być bardzo obiecującym, też biznesowo, to jest takie podejście server-lessowe, gdzie możemy dosyć łatwo konwertować płacę programisty na wartość biznesową, jaką dostarczamy.

W serverlessie jednak mamy takie podejście, że nie budujemy tego kodu infrastrukturalnego, który jest niezbędny żeby budować funkcję biznesową, bo to nam właśnie dostarcza chmura. W tym momencie możemy się fajnie skupić na budowaniu czystej wartości biznesowej, więc z mojej perspektywy, tak jak patrzę na branże, jak się zmieniała, to o ile kiedyś, lata temu rzeczywiście dosyć łatwo budowało się rozwiązania funkcjonalne dla biznesu i kodu, takiego narzutu na tę całą infrastrukturę nie było tak dużo, potem mieliśmy wyzwania związane z tym, że zanim zaprogramuje się jakaś wartość biznesową trzeba było tworzyć tego kodu infrastrukturalnego strasznie dużo, osadzać to w tych różnych środowiskach, zanim się przysłowiową pierwszą funkcję biznesową zbudowano, no to teraz serverless daje nam znowu taką szansę powrotu do szybkiej konwersji pracy programisty na wartość biznesową.

To jest taki kierunek, który jeszcze nie jest szeroko stosowany szczególnie w dużych korporacjach, o ile łatwiej to w prostszych aplikacjach mobilnych czy webowych stosować, to już zauważamy, że coraz chętniej duże przedsiębiorstwa też patrzą na rozwiązania server-lessowe i to na pewno jest taki kierunek, który zachęcamy wszystkich chcących się rozwijać w obszarze developmentu, żeby uważnie śledzili możliwości tutaj.

To jest taki kierunek, który jeszcze nie jest szeroko stosowany szczególnie w dużych korporacjach, o ile łatwiej to w prostszych aplikacjach mobilnych czy webowych stosować, to już zauważamy, że coraz chętniej duże przedsiębiorstwa też patrzą na rozwiązania server-lessowe i to na pewno jest taki kierunek, który zachęcamy wszystkich chcących się rozwijać w obszarze developmentu, żeby uważnie śledzili możliwości tutaj.

Dokładnie tak. Gdzie w tym krajobrazie widzisz DevOps? Metodologię, podejście — zależy jak kto ot definiuje. Z jednej strony można powiedzieć, że nie jest to stricte kierunek rozwoju software developmentu, ale mocno z tym związane jest to podejście.

Czy oceniasz z punktu widzenia kilku lat, kiedy ten ruch nam się rozwija, że faktycznie ta obietnica DevOpsowa połączenia dwóch działów, operacji i developmentu została zrealizowana? Czy to faktycznie jest ulepszenie?

Jestem ciekaw, jaką masz opinię na temat tego podejścia.

Z DevOpsem zawsze było trudno, bo to jest połączenie dwóch, osobnych kompetencji, zarówno operacyjnej i developerskiej. Albo ktoś jest developerem i nie bardzo chce tę perspektywę operacyjną brać na siebie, albo ktoś jest operacyjny i nie bardzo chce developerską kwestię brać na siebie. Natomiast dla mnie jest to bardzo kluczowy i krytyczny wręcz aspekt szczególnie budowania aplikacji dla dużych przedsiębiorstw, tutaj w dużej mierze chodzi o to co DevOps nam daje, czyli pełną automatyzację dostarczania kolejnych ewolucji i rozwiązań, które mamy. budowanie właśnie pipeline’u CI/CD, który pozwala nam bardzo szybko dostarczać rozwiązania bez tej potrzeby czekania na kolejne tzw. releasy dużych systemów jest wyzwaniem i jak patrzę z perspektywy naszych klientów, to tutaj szczególnie energia idzie na to, żeby jak najbardziej usprawnić te okresy, kiedy systemy nie ą dostępne i do tego jak najbardziej DevOps jest rozwiązaniem.

Istotne jest też to, żeby te elementy, które są poddawane automatyzacji coraz szerzej czerpały od tych rozwiązań, które nie były budowane w czasach, kiedy podejście DevOps było dostępne, więc tutaj też sztuką jest, żeby odpowiednio interfejsować te rozwiązania starsze, żeby też się mogły do tego pipeline’u CI/CD podłączyć i żebyśmy mogli w sposób ciągły dostarczać poprawki czy nowe rozwiązania funkcjonalne, także tutaj DevOps wydaje się być kluczowy.

Powiedziałeś już kilka ciepłych słów o serverless, czyli o takim ciekawym rozwiązaniu, które pozwala myśleć o programowaniu jako takim zestawie małych funkcji, które są uruchamiane w takich sposób bestenowy na serwerze, który jest powoływany do celów wykonania tej funkcji.

Jak to od strony biznesowej z Twojego punktu widzenia? Nie wszystko da się super zrealizować za pomocą podejścia serverless, dla niektórych zastosowań jest to podejście idealne. Czy według ciebie jeszcze mocniej serverless przeniknie to do świadomości zwłaszcza większych, szerszych rozwiązań korporacyjnych?

Wydaje mi się, że tak, bo kluczową obietnicą serverlessa jest to — z jednej strony, opór, który zauważamy jest taki, że za każde wywołanie funkcji trzeba płacić, więc to powoduje trochę zniechęcenie, bo nie bardzo wiadomo ile na koniec dnia ktoś będzie płacił za takie rozwiązanie serverlessowe.

Natomiast jeżeli popatrzymy sobie na to z drugiej strony, że im bardziej rośnie nam liczba wywołań serverlessowych, to tym większy mamy ruch transakcyjny, to znaczy, że te wywołania przynoszą bezpośrednie korzyści dla przedsiębiorstwa, w którym te aplikacje mamy.

Tutaj z perspektywy rozwiązań serverlessowych ta nieprzewidywalność pozorna jest na początku, ale potem jak ją zestawimy z tym że każde kolejne wywołanie to są konkretne tzw. monety dla danego przedsiębiorstwa, to one zaczynają się bardzo dobrze opłacać.

Z drugiej strony też to, co widać i co kiedyś było przeszkodą w przypadku serverlessa to dosyć duża latencja, jeżeli chodzi o wywoływanie funkcji. To się znacznie poprawiło w ostatnim czasie, też do serverlessa poza Pythonem, który był popularny zaczynają wchodzić te tradycyjne języki programowania również z dobrą, niską latencją, więc coraz mniej barier pojawia się przed tym serverlessem i dla mnie to jest taki powrót do obietnicy, że bardzo szybko przekładamy efekt pracy programisty na wartość biznesową, ale to trochę jeszcze wymaga mentalnego oswojenia się z nowym modelem rozliczeniowym, a w szczególności w korporacji też trzeba sobie z góry założyć pewne budżety, TSO danych rozwiązań, to pojawia się jako dosyć nowy aspekt równania, który trzeba uwzględniać i jeszcze nie wszyscy do końca wiedzą jak to przewidywać, ale na pewno zachęcam, żeby takie ćwiczenia robić, tym bardziej że jak pokazują różne statystyki innych firm, to rozwiązanie oparte o serverlessa buduje się kilkukrotnie szybciej niż tradycyjne rozwiązanie. Co prawda trzeba mieć do tego odpowiednie kompetencje, ale na koniec dnia ta korzyść zarówno w czasie dostarczenia, jak i potem w koszcie posiadania takiego rozwiązania jest na tyle obiecująca, że warto w tę stronę pójść.

Tak jak powiedziałeś — wydaje mi się, że to już nie jest problem technologiczny, tylko raczej mentalny, przekroczenie pewnej bariery. Podobnie jak musieliśmy trochę oddać kontroli wyprowadzając aplikację do chmury, tak samo też musimy teraz trochę tej kontroli oddać, po części technologicznej, może po części finansowej, jeśli chodzi o serverless, ale to, co można uzyskać jest potencjalnie znacznie większe niż ta utrata kontroli, więc też wydaje mi się, że to podejście serverless będzie coraz częściej spotykane.

Pracuję od długiego czasu dla przeróżnych startupów i mam wrażenie, że coraz więcej nas otacza — czy takich projektów green field, gdzie programiści tworzą jakiś software szyty na miarę. Tak do początku do końca, tworzą jakiś produkt, który ma podbić rynek.

Jednak nie można zapomnieć, że obok tych startupów istnieje całe mnóstwo projektów oprogramowania tzw. legacy, które już zostały stworzone jakiś czas temu, które musi być utrzymywane, które też bardzo często musi być rozwijane. Wiem, że powoli taka nisza na rynku powstaje, związana z software house’ami, też się właśnie specjalizują w utrzymywaniu, w rozwoju, w maintenance takich aplikacji typu legacy.

Czy myślisz, że ta niszowa branża będzie się rozwijać, że to będzie jakiś kierunek rozwoju? Będziemy musieli coraz bardziej specjalizować się w utrzymywaniu starszych technologii?

Chyba tak. Szczególnie pracując z przedsiębiorstwem, które zainwestowało dużo pieniędzy w rozwiązanie czy też nawet ze startupem, który zbudował już sobie rozwiązanie, no to ono już po pierwszym wdrożeniu staje się rozwiązaniem legacy, które trzeba ciągle usprawniać, prawda?

Tutaj rozumiem, że nawiązujesz do takich rozwiązań, które mają już ładnych kilka lat, często 10–15 lat funkcjonują w danym przedsiębiorstwie i tak jak mówiłem wcześniej, wymiana ich jest absolutnie nieracjonalna albo zarówno z perspektywy finansowej, ale też z takiej, że nikt nie zatrzyma biznesu na dwa lata, żeby wdrożyć nowy system centralny, więc trzeba szukać różnych, innych ścieżek do tego, żeby te systemy uaktualniać jak i dawać możliwość korporacjom dostarczania coraz to nowszych rozwiązań.

Są software house’y, które specjalizują się w utrzymaniu, natomiast utrzymanie nie jest takim fancy zadaniem dla programistów. Każdy woli tworzyć nowy kod, zamiast poprawiać czyjś. Z pomocą przychodzi tutaj ta idea takiego smart decappingu, żeby popatrzeć na takie rozwiązania jako swojego rodzaju wyzwanie inżynierskie — w końcu jesteśmy inżynierami oprogramowania, więc popatrzmy na to jako pewne wyzwanie inżynierskie.

Jak rozłożyć taki stary system na czynniki pierwsze, to zastanowić się co z tego starego systemu warto zachować, co można przepisać lub zastąpić jakimś rozwiązaniem w miarę gotowym czy też dostosowywanym. To są takie bardzo ciekawe projekty, które pozwalają popatrzeć trochę na inżynierów oprogramowania ze strony innej niż tylko tworzenie od białej kartki. W szczególności t potrzeba zbudowania właśnie API do systemów wewnętrznych, partnerskich, budowania różnego rodzaju sound boxów, to z perspektywy startupów wiesz, że wiele przedsiębiorstw udostępnia dostęp do swoich systemów, taki bezpieczny sposób soundboxowy, gdzie można sobie potrenować pewne koncepcje, rozwiązania i potem jak one się sprawdzają, to wchodzić we współpracę z takim przedsiębiorstwem, ale właśnie też tworzenie tych soundboxów jest jakimś tam elementem ciekawych wyzwań dla programistów.

Innym aspektem w pracy nad systemami, które długo mają żyć jest aspekt, żebyśmy tak budowali architekturę i rozwiązania w tym systemie, żeby ten system mógł być utrzymywany przez coraz to nowe osoby. Wiadomo, że kilkunastoletni cykl życia systemu powoduje, że osoby, które pracują nad jego rozwojem też się zmieniają, więc z jednej strony dobrze udokumentowany w kodzie system, z drugiej strony jasna, przejrzysta architektura, z trzeciej — dosyć proste konstrukcje programistyczne, żeby osoba z zewnątrz mogła tę krzywą przemian mieć bardzo krótką są niezwykle ważne, żeby planować i projektować systemy, które mają mieć ten długi czas życia.

Wiadomo, że kilkunastoletni cykl życia systemu powoduje, że osoby, które pracują nad jego rozwojem też się zmieniają, więc z jednej strony dobrze udokumentowany w kodzie system, z drugiej strony jasna, przejrzysta architektura, z trzeciej — dosyć proste konstrukcje programistyczne, żeby osoba z zewnątrz mogła tę krzywą przemian mieć bardzo krótką są niezwykle ważne, żeby planować i projektować systemy, które mają mieć ten długi czas życia.

To są aspekty, które warto uwzględniać, co nie zawsze w przypadku robienia rozwiązań dla startupów muszą być lekkie, często to są MVP, które muszą co chwilę pilotować w różne strony. Nie zawsze się to bierze pod uwagę, natomiast jak podchodzimy do współpracy z korporacjami, to trzeba ten aspekt długoterminowości życia danego systemu uwzględnić i to jest dosyć ważne wyzwanie.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-107-kierunki-rozwoju-software-developmentu/

kkempin’s dev blog

Dev and life blog.

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.

Krzysztof Kempiński

Written by

IT expert. Ruby on Rails/iOS/Elixir programmer. Blogger. Podcaster.

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.