Introduction d'un nouveau langage de programmation JVM dans un environnement d'entreprise établi

Imaginez que votre lieu de travail actuel soit une boutique Java. Il y a beaucoup de connaissances accumulées sur le langage Java et il y a un processus de construction et de déploiement complet en place pour gérer tout d'une manière fluide et agile.

Un jour, un projet arrive qui crie juste pour être écrit, disons, Ruby. Seuls les développeurs seniors ont une idée de Ruby, mais il y a une idée générale que puisque JRuby existe pour la JVM, l'infrastructure existante pourrait continuer à être utilisée et prise en charge. En outre, JRuby pourrait montrer la voie vers une meilleure façon de mettre en œuvre les applications actuelles avec moins de code, ce qui pourrait représenter une migration en cours.

N'oubliez pas que JRuby n'est qu'un exemple, il peut également s'agir de Clojure ou Groovy ou de tout autre élément exécuté sur la JVM.

La question est de savoir comment procéder pour introduire ce type de changement - le cas échéant?

Avis de non-responsabilité: je suis partial car j'écris un livre sur la programmation Polyglot sur la JVM (Shameless Plug !! - The Well-Grounded Java Developer) :)

Tout d'abord, vous ne devez introduire le changement que là où il est vraiment justifié!

Un bon point de départ est de considérer la pyramide des langages de programmation d'Ola Bini. Ola parle de langages stables, dynamiques et spécifiques au domaine.

Java est un langage stable (typé et géré statiquement) et pour diverses raisons (je peux y revenir plus tard si les gens sont intéressés) n'est pas un choix idéal pour les projets de couches dynamiques (par exemple, développement Web rapide) ou les projets de couches spécifiques à un domaine (par exemple, modélisation le domaine Enterprise Integration Pattern). Si vous avez un projet qui s'intègre dans l'une de ces couches, cela peut être un bon point de départ.

Vous pouvez également envisager d'introduire un nouveau langage au niveau de la couche stable pour remplacer Java s'il existe une fonctionnalité fondamentale qu'offre le langage alternatif. Par exemple, Scala gère simplement la concurrence d'une manière plus sûre et plus naturelle que Java.

Comme demandé, un peu plus à ce sujet. WRT Java:

• La recompilation est laborieuse
• Le typage statique peut être rigide et entraîner de longs délais de refactorisation
• Le déploiement est un processus lourd
• La syntaxe de Java n'est pas naturelle pour la production de DSL

À ce stade, vous vous demandez peut-être: «Quels types de défis de programmation correspondent à ces couches? Quelle (s) langue (s) devrais-je choisir?

Spécifique au domaine

• Build / Intégration continue / Déploiement continu
• Dev-ops
• Modélisation de modèle d'intégration d'entreprise
• Modélisation des règles métier

Dynamique

• Développement Web rapide
• Prototypage
• Consoles d'administration / utilisateur interactives
• Scripting
• Développement piloté par les tests / développement piloté par les comportements

Stable

• Code simultané
• Conteneurs d'application
• Fonctionnalité métier de base

Commencez avec un petit module à faible risque (rappelez-vous, ces langages JVM interagissent souvent magnifiquement avec le code Java existant) ou projetez. Indiquez clairement que ce sera un prototype à jeter.

Assurez-vous d'avoir étudié les aspects du cycle de vie de la programmation et de l'outillage pour ce langage. Vous voudrez vous assurer que vous pouvez TDD, exécuter des outils de construction et une intégration continue, avoir un support IDE puissant et tous ces autres facteurs. Pour certaines langues, vous devrez simplement accepter que certains outils ne sont pas là ou sont très basiques. La force du développeur et le support de l'outillage peuvent l'emporter sur la force d'un langage.

Assurez-vous qu'il existe une communauté dynamique qui peut aider votre équipe lorsqu'elle est coincée. Les groupes d'utilisateurs locaux sont encore meilleurs pour cela.

Assurez-vous que les développeurs reçoivent la formation linguistique initiale, surtout si la langue n'est pas un langage de style OO (le passage à Clojure n'est pas trivial).

C'est à ce sujet, je pense. J'ai personnellement utilisé avec succès Groovy, Scala et Clojure dans mon développement aux côtés de Java pour des tâches telles que le traitement XML, la création de sites Web rapides et le crunching de données.

Je voudrais ajouter quelques réflexions sur le sujet soulevé avec la remarque "si pas du tout". En effet, pourquoi introduire des langues supplémentaires dans l'équipe? Certes, si vous ne regardez que n'importe quel projet, la nouvelle langue peut s'avérer l'outil idéal pour la tâche. Mais si vous allez avoir de nombreux projets, vous pourriez vous retrouver avec pas mal de langues supplémentaires au fil du temps. Je ne connais pas vos cycles de maintenance et le nombre de projets, mais il est probable que l'équipe devra fournir une grande expertise dans plus de langues qu'auparavant.

D'un point de vue commercial, l'ajout de langues signifie l'ajout de complexité et de connaissances à l'équipe. Cela prolonge les périodes d'ajustement professionnel, rend plus difficile le remplacement des spécialistes de votre équipe sur la base des vacances (ou permanent) et nécessite une formation supplémentaire pour les membres de l'équipe, ce qui signifie des ralentissements à court terme.

À mes yeux, une stratégie pour faire bon accueil à l'introduction devrait également aborder ces questions en dehors des aspects purement fonctionnels. Le gain escompté vaut-il la peine supplémentaire et les inconvénients comme ceux que j'ai mentionnés ci-dessus? Si cela peut être prouvé, les taux d'acceptation pourraient être beaucoup plus élevés. Souligner ces bons investissements dans la qualification des membres de l'équipe pourrait également aider.

Je dirais, commencez par les bords. Montrez le langage dans certains codes hors production comme les scripts de construction, les plugins maven, l'exécution de rapports, etc. Une fois qu'ils voient l'utilité et la simplicité, ils peuvent être plus enclins à autoriser des projets à petite échelle, etc.