Wprowadzenie nowego języka programowania JVM do uznanego środowiska korporacyjnego

Wyobraź sobie, że twoje obecne miejsce pracy to sklep Java. Istnieje duża wiedza na temat języka Java i istnieje kompleksowy proces kompilacji i wdrażania, aby obsłużyć wszystko w sposób płynny i zwinny.

Pewnego dnia pojawia się projekt, który krzyczy, żeby napisać, powiedzmy, Ruby. Tylko starsi programiści mają jakieś wskazówki na temat Ruby, ale istnieje ogólne pojęcie, że skoro JRuby istnieje dla JVM, to istniejąca infrastruktura może być nadal używana i obsługiwana. Ponadto JRuby może wskazać drogę do lepszego sposobu implementacji bieżących aplikacji z mniejszą ilością kodu, co może oznaczać ciągłą migrację.

Pamiętaj, że JRuby to tylko przykład, może to być Clojure lub Groovy lub cokolwiek innego działającego na JVM.

Pytanie brzmi, jak byś wprowadził taką zmianę - jeśli w ogóle?

Oświadczenie: jestem stronniczy, pisząc książkę o programowaniu Polyglot na JVM (Shameless Plug !! - The Well-Grounded Java Developer) :)

Po pierwsze, zmianę należy wprowadzać tylko tam, gdzie jest to naprawdę uzasadnione!

Dobrym początkiem jest rozważenie piramidy języka programowania Oli Bini. Ola mówi o językach stabilnych, dynamicznych i specyficznych dla domeny.

Java jest stabilnym językiem (typowo statycznym i zarządzanym) iz różnych powodów (mogę się do nich później zgłosić, jeśli ludzie są zainteresowani) nie jest idealnym wyborem dla projektów warstw dynamicznych (np. Rapid Web Development) lub projektów warstw specyficznych dla domeny (np. Modelowanie domena Enterprise Integration Pattern). Jeśli masz projekt pasujący do jednej z tych warstw, może to być dobre miejsce na rozpoczęcie.

Możesz również rozważyć wprowadzenie nowego języka w warstwie stabilnej, aby zastąpić Javę, jeśli istnieje podstawowa funkcja oferowana przez język alternatywny. Na przykład Scala po prostu obsługuje współbieżność w bezpieczniejszy i bardziej naturalny sposób niż Java.

Zgodnie z życzeniem, trochę więcej na ten temat. WRT Java:

• Rekompilacja jest pracochłonna
• Pisanie statyczne może być nieelastyczne i prowadzić do długich czasów refaktoryzacji
• Wdrożenie jest procesem ciężkim
• Składnia Java nie jest naturalnym rozwiązaniem do tworzenia DSL

W tym momencie możesz zadać sobie pytanie: „Jakie wyzwania programistyczne mieszczą się w tych warstwach? Który język (języki) powinienem wybrać? ”, Pamiętaj, że nie ma srebrnej kuli, ale mam pewne kryteria, które możesz wziąć pod uwagę przy ocenie swoich wyborów.

Specyficzne dla domeny

• Kompilacja / ciągła integracja / ciągłe wdrażanie
• Dev-ops
• Modelowanie wzorca integracji korporacyjnej
• Modelowanie reguł biznesowych

Dynamiczny

• Szybkie tworzenie stron internetowych
• Prototypowanie
• Interaktywne konsole administracyjne / użytkownika
• Skrypty
• Test Driven Development / Behavior Driven Development

Stabilny

• Kod współbieżny
• Pojemniki do aplikacji
• Podstawowa funkcjonalność biznesowa

Zacznij od małego modułu niskiego ryzyka (pamiętaj, że te języki JVM często pięknie współdziałają z istniejącym kodem Java) lub projektu. Wyjaśnij, że będzie to prototyp wyrzucany.

Upewnij się, że zapoznałeś się z cyklem życia programowania i aspektami narzędziowymi dla tego języka. Będziesz chciał upewnić się, że możesz TDD, uruchamiać narzędzia do budowania i ciągłą integrację, mieć potężne wsparcie IDE i wszystkie inne czynniki. W przypadku niektórych języków wystarczy zaakceptować fakt, że niektóre narzędzia nie istnieją lub są bardzo podstawowe. Siła programisty i wsparcie dla narzędzi może przewyższać siłę języka.

Upewnij się, że istnieje aktywna społeczność, która może pomóc Twojemu zespołowi, gdy utknie. Lokalne grupy użytkowników są do tego jeszcze lepsze.

Upewnij się, że programiści przechodzą wstępne szkolenie językowe, szczególnie jeśli język nie jest językiem OO (przejście do Clojure nie jest trywialne).

To chyba tyle. Osobiście z powodzeniem korzystałem z Groovy, Scali i Clojure wraz z Javą do takich zadań, jak przetwarzanie XML, budowanie szybkich stron internetowych i robienie niektórych danych.

Chciałbym dodać kilka przemyśleń na ten temat poruszony uwagą „jeśli w ogóle”. Rzeczywiście, dlaczego należy wprowadzać do zespołu dodatkowe języki? To prawda, że ​​jeśli patrzysz tylko na jeden projekt, nowy język może okazać się idealnym narzędziem do tego zadania. Ale jeśli masz wiele projektów, z czasem może pojawić się całkiem sporo dodatkowych języków. Nie wiem o twoich cyklach konserwacji i numerach projektów, ale są szanse, że zespół będzie musiał zapewnić dość dużą wiedzę specjalistyczną w większej liczbie języków niż wcześniej.

Z biznesowego punktu widzenia dodanie języków oznacza zwiększenie złożoności i wymagań w zakresie wiedzy dla zespołu. Wydłuża to okres dostosowań zawodowych, utrudnia wakacyjną (lub stałą) wymianę specjalistów w zespole i wymaga dodatkowego szkolenia członków zespołu, co oznacza spowolnienie w krótkim okresie.

Moim zdaniem strategia przyjęcia tego wprowadzenia powinna uwzględniać takie kwestie oprócz aspektów czysto funkcjonalnych. Czy oczekiwany zysk jest wart dodatkowych kłopotów i wad takich jak wspomniane powyżej? Jeśli można to udowodnić, wskaźniki akceptacji mogą być znacznie wyższe. Pomocne może być również wskazanie tych miłych inwestycji w kwalifikacje członków zespołu.

Powiedziałbym, zacznij od krawędzi. Pochwal się językiem w niektórych nieprodukcyjnych kodach, takich jak skrypty kompilacji, wtyczki maven, uruchamianie raportów itp. Gdy zobaczą użyteczność i prostotę, mogą być bardziej skłonni pozwolić na małe projekty i tak dalej.