Sytuacja kobiet w IT w 2024 roku
11.06.20217 min
Ivan Sanchez

Ivan SanchezTech Lead

Czy warto przejść z Javy na Kotlina, pracując na backendzie

Dowiedz się, dlaczego programiści Javy z reguły nie chcą przechodzić na Kotlina, pracując na backendzie.

Czy warto przejść z Javy na Kotlina, pracując na backendzie

TL;DR - zdążyłem zauważyć, że wykorzystywanie Kotlina do rozwiązań po stronie serwera jest powolna ze względu na mieszankę strachu o swoją karierę i małej popularności tego języka. W niektórych przypadkach unikanie go w takim kontekście jest jednak uzasadnione.

Minęło już prawie pięć lat, odkąd napisałem pierwszy kod w Kotlinie, po ponad piętnastu latach korzystania z Javy. Nasz zespół nie do końca grał według zasad Javy: używaliśmy Utterlyidle zamiast Springa i wzięliśmy programowanie funkcyjne z Totallylazy. Byliśmy wielkimi fanami IntelliJ i staraliśmy się w pełni wykorzystywać narzędzia, które zapewniał dla Javy.

Już wtedy szukaliśmy czegoś poza Javą. Niektóre zespoły zainteresowały się Scalą - mieliśmy już tam nawet napisanych kilka serwisów, ale jej złożoność, trudności w pracy z bazą kodu i powolny czas kompilacji sprawiły, że język ten nie przypadł nam za bardzo do gustu.

Kiedy Google ogłosił w 2017 roku, że Kotlin staje się oficjalnym językiem Androida, inny bliski nam zespół ocenił ten język pod kątem przydatności po stronie serwera. W końcu większość z nas tego spróbowała.

Byłem pozytywnie zaskoczony tym, jaki wpływ Kotlin miał na nasz kod - wydawał się bardziej produktywny, bezpieczniejszy, a jego narzędzia, choć nie tak dojrzałe jak te Javy, były wystarczająco dobre, aby stwierdzić, że adopcja jest tego warta.

Fajnie było również odejść od języka, który wydawał się stary i rozwlekły, i odkryć, jakie style kodowania dobrze pasują do funkcji Kotlina. Doskonała interoperacyjność z Javą oznaczała, że mogliśmy zacząć polegać na istniejącym ekosystemie i systemach przejściowych, bez znaczących zakłóceń w wykonywaniu zadań.

Wkrótce moje zainteresowanie Kotlinem zaowocowało wzięciem udziału w tworzeniu http4k, biblioteki do funkcyjnej obsługi HTTP dla Kotlina i prowadzeniem warsztatu Real World Kotlin Development, aby pomóc innym zespołom próbującym przejść z Javy na Kotlina.

Później pracowałem już na innych stanowiskach, ale miałem na szczęście okazję zobaczyć Kotlina używanego po stronie serwera w różnych innych projektach. Doświadczyłem też na własnej skórze wielu rzeczy, przez które zespoły były bardzo niechętne do zaadoptowania Kotlina.

Ciekawe, że opór nie zawsze wynika z wartości samego języka. Dlaczego więc społeczność Javy, która tworzy rozwiązania po stronie serwera, nie przekonała się jeszcze do końca do Kotlina? Oto kilka powodów.

“Nie mamy czasu na naukę nowego języka”

To trochę inaczej powiedziane „jestem zbyt zajęty rąbaniem drewna, aby naostrzyć siekierę”. Często słyszę to od programistów. Zwykle jest to oznaka głębszych problemów, takich jak rosnący dług techniczny i ogólne problemy z produktywnością.

Zdrowe projekty zawsze wymagają sporo nauki. A kompetentny programista Javy może nauczyć się podstaw Kotlina w ciągu kilku godzin i będzie całkiem produktywny w ciągu kilku dni. To wszystko się opłaca, bo piszemy prostszy kod, zwiększamy produktywność i musimy radzić sobie z mniejszą ilością problemów.

“Java staje się lepsza z każdym nowym wydaniem”

To wszystko prawda: Java jest coraz lepsza. A wydania wychodzą szybciej. Z drugiej strony, wciąż jest ona daleko za Kotlinem, jeśli chodzi o np. radzenie sobie z nullami.

Może społeczność Javy nie jest przyzwyczajona do tempa ewolucji języka. Mimo to Kotlin daje okazje do wykorzystania wielu jej funkcji (i nie tylko) już teraz.

“Jesteśmy szczęśliwi z Javą”

Taki rodzaj oporu jest najcięższy do przełamania. Niewiele można zrobić, jeśli programista zwiąże swoją tożsamość zawodową z jednym językiem programowania.

Z jednej strony rozumiem, że developerzy Javy nie chcą ryzykować kariery, zapuszczając się w nieznane rejony innego języka. Może chcą być też specjalistami z dużym doświadczeniem w jednej technologii. Ma to wszystko jak najbardziej sens. 

Z drugiej jednak strony, myślę, że zobaczę jeszcze developerów Javy, którzy pozostają w tyle, bo używali Kotlina - pokazuje to jednak, że cały czasu poszukują innych narzędzi do swojej pracy, co jest dużym pozytywem, a przynajmniej dla ludzi, których pomagam zatrudniać. 

“Kotlin jest przereklamowany i ma nieznaną przyszłość”

Często się to słyszało w 2017 - to wtedy Google przyjął Kotlina jako główny język do developmentu Androida, potwierdzając tym samym, że duże firmy technologiczne interesują się jego wzrostem. 

Teraz już tego tak nie słychać ze względu na takie popularne frameworki jak Spring i Micronaut, które wykorzystują ten język. Miejmy nadzieję, że Kotlin stanie się dzięki temu bardziej widoczny dla ludzi tworzących rozwiązania po stronie serwera. 

“Korzystam z Eclipse, dlatego nie chcę przechodzić do IntelliJ”

Można śmiało powiedzieć, że Kotlin w Eclipse nie pasuje do ogólnego zamysłu JetBrains. Jest to zrozumiałe, ponieważ model biznesowy tej firmy obejmuje sprzedaż ich własnych narzędzi developerskich. I to się pewnie nieprędko zmieni, jeśli w ogóle.

Jedyną nadzieją jest tutaj osiągnięcie przez Kotlina masy krytycznej, która uzasadnia dalszą inwestycję we wsparcie języka w Eclipse. Do tego momentu programistom Kotlina będzie jednak najlepiej przy produktach JetBrains.

Moja opinia jest taka, że IntelliJ i tak jest już lepszym IDE dla Javy, więc może warto już się przenieść.

“Developerzy Kotlina są zbyt kosztowni i trudni do zdobycia” 

Ciężko to ocenić: patrząc na portale płacowe, można stwierdzić, że pensje programistów Kotlina są ogólnie nieco wyższe.

Ciężko tu cokolwiek porównywać, jeśli bierzemy pod uwagę tylko back-endowców. Ogólnie rzecz biorąc, to jeśli chodzi o Javę to właśnie tam zarabia się najwięcej - jeśli chodzi natomiast o Kotlina, to mamy tutaj za mało danych.

Widać jednak, że to Senior Java Developerzy są często pierwszymi, którzy zaczynają wykorzystywać Kotlina, co może sprawiać wrażenie, że programiści Kotlin są drodzy.

Jeżeli chodzi o rekrutację, to nie mamy problemów z przyciągnięciem programistów, którzy chcą spróbować Kotlina. Mówimy jasno, że ta praca wymaga używania nowego języka i mamy świadomość, że programiści nauczą się go dopiero w pracy. Wydaje się, że uspokaja to programistów Javy i przyciąga tych, którzy chcą uczyć się nowych rzeczy, co również dobrze wróży, jeśli chodzi o potencjalne dopasowanie.

“Kotlin jest zbyt skomplikowany”

Jednym z powodów, dla których Kotlin stanowi atrakcyjną alternatywę dla języków takich jak Scala, jest to, że osiągnął przyzwoitą równowagę między łatwością używania dla programisty a jego zaawansowanymi funkcjami. To wszystko może umożliwić obsługę Javy i przyjęcie jej przez popularne frameworki.

W praktyce takie zastrzeżenie jest zwykle związane z umiejętnościami, stylem i zasadami danego zespołu. Początkujący zwykle zaczynają pisać Kotlina tak, jak robiliby to w Javie. Gdy zaznajomią się już trochę z nowym językiem, to pewnie będą nadużywać niektórych funkcji (np. rozszerzeń i funkcji inline), czyniąc bazę kodu nieczytelną dla nowicjuszy.

Dopóki zespół nie będzie w pełni zaznajomiony z nowym językiem, to zdecydowanie polecamy korzystanie z Boring Kotlin™ tak długo, jak to tylko możliwe. Ostatecznie większość zespołu poczuje się na tyle komfortowo, aby znaleźć równowagę między wybieraniem fajnych funkcji a udostępnianiem kodu całemu zespołowi.

“Dwa języki w bazie kodu tworzą zamieszanie”

Wielu tych, którzy nie korzystali z Kotlina w prawdziwym projekcie się tego boi. W praktyce, dopóki zespół trzyma się ustaleń i pamięta, że nowy kod Kotlina musi na początku współistnieć z kodem Javy, używanie dwóch języków w jednym projekcie nie będzie sprawiało dużych problemów.

To może Ci pomóc:

„Jeśli zmiana dotyka dwóch języków, zacznij od przekonwertowania starego kodu na kod Kotlina”


W ten sposób zespół może uniknąć wielkiego przepisywania i stopniowo migrować obszary, w których musi dodać nową wartość. Nic się też nie stanie, jeśli jakiś kod będzie dalej w Javie. A będzie tak pewnie dlatego, że ten kod dalej działa i nie ma pilnej potrzeby jego refaktoryzacji.

“Lepiej nam w Javie”

Może się też zdarzyć, że dany kontekst nie wymaga nowego języka. Wszystko działa dobrze, zespół wykonuje zadania w akceptowalnym tempie i dobrze rozumie problem, który Kotlin mógłby pomóc rozwiązać.

Z naszego doświadczenia wynika jednak, że to wyjątek, a nie reguła. To, że ktoś czuje się lepiej z Javą, wynika z ogólnego braku czasu lub zainteresowania nauką, a nie z braku obszarów, które wymagają poprawy.

Trudno też doświadczyć korzyści płynących z Kotlina, dopóki nie spróbuje się go w prawdziwym projekcie. Wprowadzenie nowego języka, nawet eksperymentalnie, może wprowadzić też sporo stresu.

W takich przypadkach polecam „Naukę podczas pracy” (w formie dojo kodowania lub nieformalnych spotkań itp.), aby stworzyć bezpieczne środowisko, w którym będzie można w taki sposób eksperymentować.

Takie podejście pozwala zespołowi ocenić wykorzystanie Javy, oraz to, czy warto inwestować w Kotlina.

“Nie widzę nic dobrego, co Kotlin mógłby nam dać”

Czasem programiści Javy nie są świadomi ograniczeń języka lub są do nich zbyt przyzwyczajeni. W innych przypadkach odrzucają każdą alternatywę, która sprawia, że kwestionują swój obecny język.

Nie zagłębiając się już w szczegóły, można powiedzieć, że zwięzłość i bezpieczeństwo Kotlina to jego główne zalety. Niektórzy powiedzą jednak, że nie widzą problemu z tym że kod Javy jest gigantyczny, a poza tym to już teraz piszą bezpieczny kod.

Łatwo jest odrzucić Kotlina, zanim się go wypróbuje, a więc wielu będzie nadal szukało powodów, aby nie spróbować.

Podsumowanie

Przyjęcie nowego języka programowania, zwłaszcza w projektach, które trwają, stanowi spore wyzwanie dla większości zespołów. Ważne jest, aby zaakceptować fakt, że opieranie się zmianie jest silnie związane z kontekstem i będzie wynikało z potrzeb projektu i powodów osobistych, a także samego języka.

Mając to na uwadze, nadal zachęcam programistów tworzących backend w Javie, aby spróbowali z Kotlinem. Może to uwydatnić jakieś problemy poza kodem.


Oryginał tekstu w języku angielskim możesz przeczytać tutaj

<p>Loading...</p>