Kiedy coś jest jak się wydaje przestarzałe, ale nadal działa, można uznać, że chyba jednak przestarzałe nie jest, czy nie? To jeden z tych scenariuszy „jeśli coś się jeszcze nie zepsuło, to po co to naprawiać”. I w wielu przypadkach faktycznie może to być skuteczna strategia.
Ale w świecie rozwoju oprogramowania takie podejście wiąże się z wieloma zagrożeniami.
Korzystanie z przestarzałych technologii, takich jak JSF (JavaServer Faces) z JSP (JavaServer Pages), staje się coraz bardziej kłopotliwe i ostatecznie może spowodować utratę pieniędzy, które można by zaoszczędzić w ramach aktualizacji technologii.
Warto porozmawiać o zagrożeniach wynikających z używania przestarzałych technologii na przykładzie JSF i JSP. I warto zauważyć, że te dwa rozwiązania podlegają oficjalnie deprecjacji.
Dlaczego JSF z JSP są przestarzałe?
Zanim przejdziemy do zagrożeń, wyjaśnijmy, dlaczego wciąż korzystamy z takich technologii i co jest w nich tak problematyczne.
Najczęstszym powodem jest to, że
wiele rozwiązań zbudowanych z wykorzystaniem starego stacku technologicznego to rozwiązania, które można uznać za wystarczająco dobre, przynajmniej na razie. Nawet jeśli nie są one tak łatwe do poprawienia i aktualizacji, firmy są przyzwyczajone do starych sposobów, które pozwoliły im dobrze funkcjonować przez wiele lat. Zwłaszcza, że przejście na nowoczesne, znacznie bardziej popularne technologie wiąże się z bardzo dużymi kosztami. Często mówimy o przebudowie potężnych systemów, których przygotowanie trwało wiele lat. Oczywiście jest to całkowicie zrozumiałe, jeśli nie liczymy się z ryzykiem. Ale nie uprzedzajmy faktów.
Trzeba przyznać, że liczne problemy JSP i JSF są bardzo charakterystyczne dla całego problemu „przestarzałej techniki”. Wszystko zaczyna się od kwestii technicznych i faktu, że przez lata świat technologii rozwijał się w znacznym stopniu, podczas gdy te rozwiązania pozostawały w tyle.
Natomiast pozostawanie przywiązanym do starych technologii to trochę jak odmowa wymiany swojego starego samochodu z przebiegiem 750 000+, mimo że wymaga on comiesięcznej wizyty u mechanika i spala 3x więcej paliwa w porównaniu z nowym.
Tak więc, w skrócie, porozmawiajmy o najistotniejszych wadach JavaServer Faces.
1. Szybki rozwój to tani rozwój, natomiast JSF utrudnia proste zadania.
2. Jest stosunkowo trudna do nauczenia, więc trudno rozbudować zespół, jeśli jest taka potrzeba w szybkim czasie.
3. Jest niekompatybilny z wieloma standardowymi technologiami Javy
4. Utrudnia testowanie w porównaniu z innymi, bardziej nowoczesnymi alternatywami.
5. Front i back end są ściśle sprzężone, co skutkuje dłuższym i droższym czasem rozwoju i wymaga full-stack developerów do wykonania pracy.
6. Jest to dedykowany standard interfejsu użytkownika dla Java EE 8, który wprowadzono 17 kwietnia 2017 roku.
7. To rozwiązanie jest podatne na problemy z wydajnością.
8. JSP i JSF oznaczają strony renderowane po stronie serwera, które są nieefektywne i dość niezgrabne.
9. I wiele więcej.
Konsekwencje tych problemów sięgają od wyższego i dłuższego czasu opracowania do braku możliwości załadowania stron internetowych z powodu przeciążenia serwera. Co gorsza, JSF nie daje deweloperom odpowiednich narzędzi do naprawy wielu z tych problemów.
Dlaczego trzymanie się przestarzałego stacku technologicznego jest ryzykowne?
Istnieje wiele wyzwań, z którymi muszą zmierzyć się deweloperzy, gdy mają do czynienia z przestarzałym stackiem technologicznym, ale aby naprawdę zrozumieć problem, musimy spojrzeć na niego z szerszej perspektywy. Warto przyjrzeć się więc kilku najistotniejszym zagrożeniom związanym z pracą z przestarzałymi, a czasem wręcz wygasającymi technologiami.
Rosnące koszty utrzymania i rozwoju
COBOL to język programowania, który po raz pierwszy został zaprojektowany w 1959 roku. Przez lata wiele z jego wersji było szeroko wykorzystywanych przez instytucje finansowe, rządy i przedsiębiorstwa. W tej chwili nie ma absolutnie żadnych szans, abyś usłyszeć o tym w poważnej rozmowie o nowoczesnym oprogramowaniu. I choć rzeczywiście jest to przestarzała technologia, to nadal jest bardzo często stosowana w wielu uznanych przedsiębiorstwach, przede wszystkim w bankowości. Zatem na czym polega problem?
Cóż, jest to bardzo drogie rozwiązanie.
Obecnie młodzi programiści nie uczą się tego języka, a doświadczeni często są bliżej emerytury niż szukają nowej pracy, więc bardzo trudno jest znaleźć ludzi do utrzymania systemów opartych na COBOL.
A jeśli nawet takie osoby są dostępne, to zwykle oczekują znacznie wyższych wynagrodzeń niż średnia rynkowa. Zauważyliśmy już, że bardzo podobny proces dzieje się z JSF i JSP, co stawia firmy w trudnej sytuacji.
Wady przestarzałych systemów i oczekiwania współczesnych użytkowników (i deweloperów)
Jednym z najistotniejszych wyzwań dla firm w nowej erze jest tworzenie przyszłościowego oprogramowania. Oznacza to, że jest łatwo dostępna dla każdego typu użytkownika, bez względu na urządzenie, co oczywiście obejmuje też mobilne konsole do gier, lodówki czy roboty odkurzające.
Użytkownicy oczekują, że uniwersalna dostępność i platformy oparte na JSF nie mogą być nawet RESTful. Oczywiście, to skrajny przykład. Większość aplikacji zbudowanych w JSF nie będzie wymagała takich funkcji, ale jest to tylko jeden z wielu przykładów ograniczeń, które wynikają z prowadzenia prac przy użyciu przestarzałych technologii.
Ponadto, są one po prostu nieatrakcyjne dla programistów, którzy szukają wyzwań i chcą budować przełomowe oprogramowanie. Nie widzą w tym rozsądnej ścieżki kariery, bo to nie jest przyszłościowe rozwiązanie. Świat techniki pójdzie do przodu, a ich umiejętności przestaną być poszukiwane.
Jaka jest alternatywa?
Rosnące ryzyko i problemy rozwojowe, jakie wiążą się z używaniem JSP, doskonale odzwierciedlają statystyki popularności technologii. W obecnej erze tworzenia oprogramowania nie ma powodu, by wybierać JSF, jeśli budujemy coś od podstaw. A jednocześnie coraz więcej firm podejmuje trudną decyzję o aktualizacji stacku, aby sprostać wymaganiom nowoczesnych użytkowników i urządzeń. Według ostatniego badania JVM, 58% aplikacji uruchamianych przez JVM wykorzystuje Spring Boot, podczas gdy tylko 8% wykorzystuje JSF, a różnica ta zwiększa się z każdym rokiem.
Niezależnie od tego, czy jest to Spring Boot czy Spring MVC, nowoczesne frameworki obsługują zdecydowaną większość problemów związanych z wiekiem JSF. Na tej samej zasadzie frameworki takie jak Angular czy Vue.js z powodzeniem zastępują JSP. Oczywiście rozwiązują one nie tylko kwestie techniczne. Na rynku dostępnych jest znacznie więcej deweloperów, co pozwala na znacznie szybsze uruchomienie projektu i łatwiejsze rozbudowanie zespołu. Oznacza to również, że otrzymujemy super aktywne społeczności, które wspierają się nawzajem i dzielą gotowymi rozwiązaniami i rozszerzeniami. W rezultacie rozwój staje się tańszy i szybszy, a my w tym samym czasie otrzymujemy znacznie lepsze oprogramowanie.
Jak trudne jest przejście na nowocześniejsze technologie?
To podchwytliwe pytanie, bo w większości przypadków nie chodzi o trudność czy nawet koszt, ale o konieczność.
Coraz częściej decyzja o odejściu od przestarzałych technologii to kwestia przetrwania. Oczywiście, decyzja nigdy nie jest łatwa. To zawsze trudne zadanie, które wymaga analizy, zaangażowania, czasu i budżetu. Ale te zagrożenia, które wymieniliśmy, nie znikną. Wręcz przeciwnie, każdy rok przybliża technologie takie jak JSF do stania się częścią historii rozwoju oprogramowania, a nie nowoczesnej inżynierii oprogramowania.
Oczywiście każde indywidualne oprogramowanie wymaga odpowiedniej analizy. Nie zawsze radykalna decyzja o całkowitej zmianie technologii jest właściwa, ale samo jej rozważenie to świetny początek. A jeśli uważają Państwo, że pożegnanie z dotychczasowym stackiem technologicznym może być dobrym zwrotem dla Twojej firmy,
prosimy o kontakt, pomożemy Państwu dokonać właściwego wyboru dla firmy.
Łukasz Caputa
Sales Engineer
