Introduzione di un nuovo linguaggio di programmazione JVM in un ambiente aziendale consolidato

Immagina che il tuo attuale posto di lavoro sia un negozio Java. Esistono molte conoscenze approfondite sul linguaggio Java e un processo completo di compilazione e implementazione in atto per gestire tutto in modo fluido e agile.

Un giorno arriva un progetto che urla solo per essere scritto, diciamo, in Ruby. Solo gli sviluppatori senior hanno qualche idea su Ruby, ma c'è un'idea generale che, poiché JRuby esiste per la JVM, le infrastrutture esistenti potrebbero continuare a essere utilizzate e supportate. Inoltre, JRuby potrebbe mostrare la strada per un modo migliore di implementare le applicazioni attuali con meno codice, in modo da rappresentare una migrazione in corso.

Ricorda che JRuby è solo un esempio, potrebbe anche essere Clojure o Groovy o qualsiasi altra cosa venga eseguita sulla JVM.

La domanda è: come faresti a introdurre questo tipo di cambiamento, se non del tutto?

Disclaimer: sono di parte mentre scrivo un libro sulla programmazione di Polyglot su JVM (Shameless Plug !! - The Well-Grounded Java Developer) :)

In primo luogo, dovresti introdurre il cambiamento solo dove è veramente giustificato!

Un buon punto di partenza è considerare la piramide del linguaggio di programmazione di Ola Bini. Ola parla di lingue stabili, dinamiche e specifiche del dominio.

Java è un linguaggio stabile (digitato staticamente e gestito) e per vari motivi (posso approfondirli in seguito se le persone sono interessate) non è la scelta ideale per progetti di livello dinamico (ad es. Rapid Web Development) o progetti di livello specifici del dominio (ad es. Modellazione il dominio Enterprise Integration Pattern). Se hai un progetto che si adatta a uno di quei livelli, quello può essere un buon punto di partenza.

Puoi anche prendere in considerazione l'introduzione di un nuovo linguaggio a livello stabile per sostituire Java se esiste una caratteristica fondamentale che offre il linguaggio alternativo. Ad esempio, Scala gestisce semplicemente la concorrenza in un modo più sicuro e naturale rispetto a Java.

Come richiesto, ancora un po 'su questo. WRT Java:

• La ricompilazione è laboriosa
• La digitazione statica può essere poco flessibile e portare a lunghi tempi di refactoring
• La distribuzione è un processo pesante
• La sintassi di Java non si adatta perfettamente alla produzione di DSL

A questo punto, potresti chiederti: “Che tipo di sfide di programmazione rientrano in questi livelli? Quale lingua (e) dovrei scegliere? ”, Ricordi che non esiste un proiettile d'argento, ma ho alcuni criteri che potresti prendere in considerazione quando valuti le tue scelte.

Domain-Specific

• Build / Integrazione continua / Implementazione continua
• Dev-ops
• Modellazione di modelli di integrazione aziendale
• Modellazione di regole aziendali

Dinamico

• Rapido sviluppo Web
• Prototipazione
• Console interattive di amministrazione / utente
• Scripting
• Test Driven Development / Behavior Driven Development

Stabile

• Codice concorrente
• Contenitori per applicazioni
• Funzionalità core business

Inizia con un piccolo modulo a basso rischio (ricorda, questi linguaggi JVM spesso interagiscono magnificamente con il codice Java esistente) o progetto. Metti in chiaro che questo sarà un prototipo da buttare via.

Assicurati di aver studiato il ciclo di vita della programmazione e gli aspetti relativi agli strumenti per quella lingua. Dovrai assicurarti di poter TDD, eseguire strumenti di costruzione e integrazione continua, avere un potente supporto IDE e tutti questi altri fattori. Per alcune lingue dovrai solo accettare che alcuni strumenti non ci sono o sono molto semplici. La forza dello sviluppatore e il supporto degli strumenti può superare la forza di una lingua.

Assicurati che ci sia una comunità vibrante che possa aiutare la tua squadra quando rimangono bloccati. I gruppi di utenti locali sono ancora migliori per questo.

Assicurati che gli sviluppatori ricevano la formazione linguistica iniziale, specialmente se la lingua non è un linguaggio in stile OO (passare a Clojure non è banale).

Questo è tutto, penso. Personalmente ho usato con successo Groovy, Scala e Clojure nel mio sviluppo insieme a Java per attività come l'elaborazione XML, la creazione di siti Web rapidi e l'esecuzione di alcuni dati.

Vorrei aggiungere alcune riflessioni sull'argomento sollevato con l'osservazione "if at all". Infatti, perché si dovrebbero introdurre altre lingue nel team? È vero, se stai solo guardando un singolo progetto, la nuova lingua potrebbe apparire come lo strumento ideale per l'attività. Ma se hai molti progetti, potresti finire con diverse lingue aggiuntive nel tempo. Non conosco i tuoi cicli di manutenzione e numeri di progetto, ma è probabile che il team dovrà fornire parecchie competenze in più lingue rispetto a prima.

Da un punto di vista aziendale, aggiungere lingue significa aggiungere complessità e requisiti di conoscenza al team. Ciò prolunga i periodi di adattamento professionale, rende più difficili i rimpiazzi (o permanenti) di specialisti nella tua squadra e richiede una formazione aggiuntiva per i membri del team, il che significa rallentamenti a breve termine.

Ai miei occhi, una strategia per dare il benvenuto all'introduzione dovrebbe affrontare tali questioni oltre ad aspetti puramente funzionali. Il guadagno atteso vale la pena in più e gli svantaggi come quelli che ho menzionato sopra? Se ciò può essere dimostrato, i tassi di accettazione potrebbero essere molto più elevati. Sottolineare anche quei bei investimenti nella qualifica dei membri del team.

Direi, inizia dai bordi. Mostra la lingua in alcuni codici non di produzione come script di compilazione, plugin di maven, esecuzione di report, ecc. Una volta che vedono l'utilità e la semplicità, possono essere più inclini a consentire progetti su piccola scala e così via.