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

Dichiarazione di non responsabilità: sono prevenuto mentre sto scrivendo un libro sulla programmazione di Polyglot sulla JVM (Shameless Plug !! - The Ben-Grounded Java Developer):)

In primo luogo, dovresti introdurre la modifica solo dove è veramente giustificata!

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 è una lingua stabile (gestita e gestita staticamente) e per vari motivi (posso approfondirli successivamente se le persone sono interessate) non è una scelta ideale per i progetti di livello dinamico (ad esempio Rapid Web Development) o per il livello specifico del dominio progetti (es. modellazione del dominio Pattern di integrazione aziendale). Se hai un progetto che rientra in uno di questi livelli, allora può essere un buon punto di partenza.

Puoi anche considerare l'introduzione di una nuova lingua sul layer stabile per sostituire Java se esiste una caratteristica fondamentale offerta dalla lingua alternativa. Ad esempio, Scala gestisce semplicemente la concorrenza in un modo più sicuro e più naturale di Java.

Come richiesto, un po 'di più su questo. WRT Java:

• La ricompilazione è laboriosa
• La tipizzazione statica può essere inflessibile e portare a lunghi tempi di refactoring
• La distribuzione è un processo pesante
• La sintassi di Java non è una scelta naturale per la produzione di DSL

A questo punto, ti starai chiedendo: "Che tipo di sfide di programmazione si adattano a questi livelli? Quale lingua (s) dovrei scegliere? ", Ricorda che non esiste una pallottola d'argento, ma ho alcuni criteri da prendere in considerazione quando valuti le tue scelte.

Domain-specifica

• Creazione / Integrazione continua / Distribuzione continua
• Dev-ops
• Modellazione di modelli di integrazione aziendale
• Modelli di regole aziendali

Dinamico

• Sviluppo rapido del Web
• Prototipazione
• Console di amministrazione / utente interattive
• Scripting
• Sviluppo guidato da test / Sviluppo guidato dal comportamento

stabile

• Codice concorrente
• Contenitori di applicazioni
• Funzionalità del core business

Inizia con un modulo a basso rischio (ricorda che queste lingue JVM interagiscono spesso con il codice Java esistente splendidamente) o progetto. Metti in chiaro che questo sarà un prototipo da buttare via.

Assicurati di aver studiato gli aspetti del ciclo di vita della programmazione e degli strumenti per quella lingua. Dovrai assicurarti di poter TDD, eseguire strumenti di costruzione e integrazione continua, avere un supporto IDE potente e tutti questi altri fattori. Per alcune lingue devi semplicemente accettare che alcuni strumenti non sono presenti, o è molto semplice. La forza dello sviluppatore e il supporto degli strumenti possono superare la forza di un linguaggio.

Assicurati che ci sia una comunità vibrante in grado di aiutare la tua squadra quando si blocca. I gruppi di utenti locali sono ancora meglio per questo.

Assicurati che gli sviluppatori ottengano l'addestramento linguistico iniziale, soprattutto se la lingua non è un linguaggio di stile OO (passare a Clojure non è banale).

Penso che sia così. Ho personalmente utilizzato con successo Groovy, Scala e Clojure nel mio sviluppo insieme a Java per attività quali l'elaborazione XML, la creazione di siti Web rapidi e l'esecuzione di alcuni scricchiolii di dati.

Vorrei aggiungere alcune considerazioni sull'argomento sollevato con l'osservazione "se non del tutto". In effetti, perché dovremmo introdurre altre lingue nella squadra? È vero, se stai guardando un singolo progetto, la nuova lingua potrebbe essere lo strumento ideale per l'attività. Ma se hai intenzione di avere molti progetti, potresti finire con un po 'di lingue aggiuntive nel tempo. Non conosco i tuoi cicli di manutenzione e i numeri dei progetti, ma è probabile che il team dovrà fornire parecchia esperienza in più lingue rispetto a prima.

Dal punto di vista del business, l'aggiunta di lingue implica l'aggiunta di complessità e requisiti di conoscenza al team. Questo prolunga i periodi di aggiustamenti professionali, rende più duri 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 rendere l'introduzione gradita dovrebbe affrontare tali questioni oltre agli aspetti puramente funzionali. Il guadagno atteso vale il problema in più e gli svantaggi come quelli che ho menzionato sopra? Se ciò può essere dimostrato, i tassi di accettazione potrebbero essere molto più alti. Indicare anche quei bei investimenti nella qualificazione dei membri del team.

Direi, inizia dai bordi. Mostra il linguaggio in alcuni codici di non produzione come script di compilazione, plug-in Maven, report in esecuzione, ecc. Una volta visualizzati l'utilità e la semplicità, potrebbero essere più inclini a consentire il progetto su piccola scala e così via.