Korzystajac z najnowszych dobrodziejstw w javie mozna pisac naprawde przyjemnie. Ale co z tego jesli sporo z tego swiata to projekty legacy o ktore czesto nikt nie dbal przez lata?
I szczerze nie wierze, ze cos takiego jest oplacalne. Czyli, ze 'lepiej nie dotykac dopoki sie nie rozlatuje'.
A Wy co o tym myslicie?
Projekty legacy się cały czas utrzymuje, usuwa błędy, dodaje małe funkcjonalności, które nie wymagają zmian architektury, aktualizuje formaty raportów by były zgodne z nowymi wymaganiami czy regulacjami, optymalizuje wąskie gardła (to rzadziej) itp itd
A update wersji frameworka czy samego jezyka?
Albo korzystanie z jakis starych serwerow aplikacji a start aplikacji to 1h. Naprawde nie warto takich rzeczy upgradowac?
A ludziom przy tym pracujacym placi sie zreszta chyba najwiecej.
Wszystko co robią programiści musi wynikać z jakiejś potrzeby biznesowej. Taki jest model zarządzania w korporacjach. Jeśli chcecie podnieść wersję frameworka czy zmienić język to musicie przekonać zarząd, że zainwestowanie zasobów w to zadanie przyniesie im zysk w interesującej ich perspektywie czasowej (np inwestycja zwróci się z mniej niż 2 lata, bo upgrade potrwa pół roku, a potem nowe funkcjonalności będą wchodzić 2x szybciej). Aby mieć siłę przekonywania najpierw trzeba udowodnić, że wiecie jak system działa, trzeba w nim porzeźbić i odnieść jakieś sukcesy. Zarząd raczej niechętnie będzie patrzył na świeżych programistów, którzy będą głównie narzekać, a nie dowozić rozwiązania na aktualne potrzeby.
To co ma znaczenie z punktu widzenia biznesowego to to ile da się zarobić sprzedając dany produkt lub usługę. Ani zarządu ani klienta niespecjalnie obchodzą frameworki użyte w projekcie. To nie jest niczym dziwnym. Jeżeli korzystam z jakiejś tam strony internetowej to zwykle nie kręcę nosem jeżeli jest napisana w technologii do której nie czuję respektu. Np to forum 4programmers jest napisane w PHP w autorskim frameworku i ja w czymś takim niechętnie bym grzebał. Jednak chętnie korzystam :) Interesuje mnie to czy forum jest stabilne, czy informacje są bezpieczne (np czy można je wykraść, albo czy przepadają wraz z awariami), czy działa dobrze wtedy, gdy z niego korzystam.
Na każdą przypadłość systemu można znaleźć jakieś obejście. Np jeśli aplikacja ma wycieki pamięci, ale np w nocy się jej nie używa to można robić nocne restarty (tak było w pewnym systemie legacy w Sabre w którym pracowałem). Jeśli aplikacja wstaje godzinę to można popracować nad rozwiązaniem, w którym może chodzić wiele wersji aplikacji jednocześnie i dzięki temu wdrażanie nowej wersji nie jest bolesne. Jeżeli wersja frameworka, którą używamy ma jakąś lukę bezpieczeństwa to można nawet ręcznie zbackportować odpowiednią łatę do tego frameworka lub można zrobić obejście problemu w kodzie aplikacji.
Historii w których ktoś przepisuje dużą i wdrożoną już aplikację całkowicie od zera jest niewiele. Rozsądni ludzie robią to przyrostowo. Dzieli się biznesową kobyłę na kawałki i wymienia się bebechy po kawałku w miarę potrzeb. Jedyną historią o przepisywaniu od zera dużej i wdrożonej aplikacji jest historia przeglądarki od Netscape, która z powodu przepisywania od zera i wynikłych z tego powodu obsuw stała się przestarzała i straciła popularność na rzecz Internet Explorera. Przepisywanie od zera okazało się samobójstwem, ponieważ brakło zasobów by aktualizować działającą już wersję, a nowa ciągle nie była kompletna, więc klienci przeszli na produkt konkurencji. Internet Explorer być może nie był dziełem sztuki, ale spełniał wymagania klientów lepiej niż strategia przesadnie ambitnych programistów.
Nie no. Ja nie mam na myśli przepisywania czegoś od zera. Daleki jestem od takich pomysłów.
A jedynie miałem na myśli rzeczy, które pozwolą pracować przy tym szybciej.
W stylu:
Spring 3 -> 4
Java 5 -> 8
Wymiana serwera aplikacji
Rzeczy realne w skończonym czasie.
Biznes to jedno, ale jest też często wielu programistów pracujących przy tym od lat, którym od dawna nic się nie chce.
Dużo zależy od przypadku. Zmiana Javy 5 na Javę 8 może wydawać się trywialna, ale praktyka może być inna. Np:
Jednak jeśli posiedzisz chwilę w projekcie i z powodzeniem dowieziesz jakieś funkcjonalności to myślę, że będziesz mógł spokojnie wynegocjować aktualizację wersji Javy.
Biznes to jedno, ale jest też często wielu programistów pracujących przy tym od lat, którym od dawna nic się nie chce.
Może zabrzmię groteskowo, ale dorosły mężczyzna załatwia sprawy sam, a nie płacze że inni nie zrobili :) Inni programiści mogą mieć inne priorytety niż ty. Stara wersja Javy czy Springa to coś co można rozpoznać od razu. Projekt może mieć jednak dużo większe problemy, typu duża złożoność cyklomatyczna utrudniająca tworzenie kodu, małe pokrycie testami automatycznymi czy nawet ogólny chaos. Jak wejdziesz do konkretnego projektu to zobaczysz co jest największym wyzwaniem i co ma największą wartość biznesową.
Nie wiem czemu traktujesz mnie z góry. Zdaje sobie z tego wszystkiego sprawę, jednak piszę bardziej ogólnie a nie o swoim przypadku.
A płakać nie płaczę bo ten problem akurat w tej chwili nie do końca mnie dotyczy.
A ogólnym pytaniem było czy wiekszość świata javy jest właśnie legacy i raczej się nic nie zmienia dopóki nie stanie się pod murem.
A także jak można takiego stanu uniknąć. Bo według mnie zazwyczaj problemem są ludzie, którym nie przeszkadza codzienne hakowanie / spawanie systemu by się nie rozleciał.
Oprócz ludzi do problemów dochodzi polityka.
Generalnie problemy techniczne są dość trywialne wobec organizacyjno-politycznych.
Kiedyś, na początku mojej komercyjnej kariery, zadawałem podobne pytania co ty tutaj. Szukałem "normalnej" firmy, w której nie ma "gównianego kodu" i przerośniętych "biznesowych kobył". Później zrozumiałem, że realia prawie każdego projektu są takie, że w kodzie tworzy się skomplikowana sieć powiązań, często cyklicznych, a to z kolei powoduje, że ciężko modernizować kod krok po kroku. W Sabre pracowałem nad projektem legacy i nasz team lead, spoko koder w miarę ogarniający system, próbował rozciąć przerośnięte moduły "common" czy tam jakiś "core" i chyba na własną rękę siedział nad tym tygodniami i się poddał.
Hakowanie systemu to chętnie wybierana droga na skończenie zadania, bo wydłużanie terminów dla wprowadzenia szerokich aktualizacji jest mało prawdopodobne jeśli nie mamy dobrego alibi. Wymagania systemów ewoluują i ciężko wymyślić architekturę, która będzie optymalna na wiele lat czy nawet miesięcy naprzód. Obecnie pracuję w systemie opartym o mikroserwisy i te sprawdzają się nieźle. Mikroserwisy są na tyle małe, że np wymianę biblioteki do dostępu do bazy danych (z Lift Mappera na Slicka 3) w pewnym mikroserwisie zrobiłem w ciągu jednego sprintu przy okazji rozwiązywania problemu z wydajnością. Wymiana warstwy dostępu do bazy danych we wszystkich mikroserwisach naraz zajęłaby pewnie wiele miesięcy i ciężko byłoby przekonać do tego zarząd.
Zakładasz też, że problem dotyczy tylko Javy, a prawda jest taka, że problem dotyczy wszystkich dużych projektów. Duże zwykle były rozwijane przez wiele lat, więc logiczne że nie dało się ich stworzyć w technologiach, których jeszcze nie było, więc jeśli nie były aktualizowane to są przestarzałe. Liczne powiązania w kodzie uniemożliwiają stopniową aktualizację architektury. Nawet migracja z Pythona 2 na Pythona 3 w Linuksowych dystrybucjach była bolesna i chyba nawet takie Ubuntu dalej nie przeniosło się całkowicie na Pythona 3 - mimo, że mają sporo programistów.
Moim zdaniem problem leży w programistach właśnie, a nie w zarządach. Zarząd nie jest w stanie określić czy pomysły programistów są słuszne. Nie można zaprzestać rozwoju projektu na wiele miesięcy, bo zmiany na rynku sprawią, że produkt przestanie spełniać wymagania klientów i regulatorów. Rozwój musi odbywać się płynnie, a zarząd musi widzieć, że zmiany przynoszą jakąś korzyść. Jak na razie najlepszym rozwiązaniem dla aplikacji biznesowych jest według mnie architektura mikroserwisów komunikujących się po REST/ JSON. Dzięki takiemu podejściu:
W skrócie - problem leży w programistach, którzy nie potrafią tworzyć systemów, które można płynnie (po kawałku) modernizować.
Bardzo fajna odpowiedź, dzięki.
Napisałem o Javie bo w tym pracuję, no i to najczęściej projekty napisane w Javie żyją już od dawien dawna.A pewnie jakbym wziął stosunkowo młodą technologię to sprawy wyglądałyby zupełnie inaczej. Przynajmniej tak sobie to wyobrażam. Co nie zmienia faktu, że projekt rozpoczęty teraz vs z 2005 w Javie na początku również dużo lepiej by wyglądał.
Zetknąłem się z mikroserwisami najpierw, później z czymś legacy i był to dla mnie nieco szok kulturowy. Dlatego doceniam właśnie możliwości mikroserwisów - mimo, że to w pewnym sensie tylko nowy buzzword.
I również zgadzam się, że wina raczej tkwi w programistach. Mnie o tyle nie bolał 'brak zmian' sam w sobie, to brak jakiejkolwiek rozmowy o ewentualnych zmianach, w sensie przedyskutowania lub w ramach eksperymentu/PoC sprawdzenie czy dana 'akcja' może się udać, a za to była zwykła bierność i czuć było, że niektóre osoby chcą sobie zagwarantować emeryturę w ten sposób.
Pytanie tylko czy to problem ze większość pracy to systemy legacy? Bo przecież zwykle nie chodzi o ich przepisywanie a rozwijanie, a to można zwykle ładne odgrodzić od starego kodu jakimiś adapterami i fasadami. Widziałem troche takich projektów gdzie obok modułów rodem z javy 1.4 (bez generyków i foreach) był kod z javy 8.
Uwazam, ze nasza rola jest to, zeby zagwarantowac dalszy rozwoj projektu. Czy to za pomoca modularyzacji i wywalaniem starych kawalkow czy wlasnie oddzieleniem sie od starej warstwy kodu.
Niestety jeszcze nigdy nie widzialem, zeby ktos staral sie faktycznie dbac o starszyp rojekt a sam glowa muru nie przebije.
To prawda, ze klienta czy biznes nie obchodzi co tam jest pod spodem. Ale nie wierze, ze nie robienie czegokolwiek jest oplacalne.
No to słabo trafiłeś. Już kilka starych projektów ponaprawiałem z różnymi zespołami. W jednym przypadku była to długa kilkuletnia praca: każdy nowy kawałek lepiej i stopniowe poprawianie różnych warstw, aż z dramatycznego spaghetti w JSP zrobiło się całkiem standardowe straszydło w JavaEE /EJB (na tamte czasy nowoczesne).
Warto mieć do tego odpowiednie podejście i nie bać się ruszać kodu. Trzeba dopisywac testy - choć na początku to jest mordęga :-(. Potem tylko zasada - nie pogarszamy (jakiś sonar / narzędzie do metryk i smrodów się przydaje). Podczas dopisywania nowych funkcjonalności i naprawiania bugów staramy się poprawiać okolice i jakoś to idzie.
To nawet jest satysfakcja jak po jakimś czasie - taki stary projekt przestaje bardzo śmierdzieć. I to nie jest tak, że jest przepisany, bo polepszeniu ulegają tylko te fragmenty gdzie się coś dzieje i ktoś zagląda. Może nawet nadal 80% projektu to syf - ale te 10-20% kodu gdzie się pracuje jest doprowadzone do stanu akceptowalności.