Einführung einer neuen JVM-Programmiersprache in eine etablierte Unternehmensumgebung

Stellen Sie sich vor, Ihr aktueller Arbeitsplatz ist ein Java-Shop. Es gibt viel Wissen über die Java-Sprache und es gibt einen umfassenden Erstellungs- und Bereitstellungsprozess, um alles reibungslos und agil zu handhaben.

Eines Tages kommt ein Projekt auf den Markt, das nur schreit, um beispielsweise in Ruby geschrieben zu werden. Nur die leitenden Entwickler haben eine Ahnung von Ruby, aber es gibt eine allgemeine Vorstellung, dass die vorhandene Infrastruktur weiterhin verwendet und unterstützt werden könnte, da JRuby für die JVM existiert. Außerdem könnte JRuby den Weg zu einer besseren Implementierung der aktuellen Anwendungen mit weniger Code aufzeigen, sodass dies eine fortlaufende Migration darstellen könnte.

Denken Sie daran, dass JRuby nur ein Beispiel ist. Es kann sich auch um Clojure oder Groovy handeln oder was auch immer auf der JVM ausgeführt wird.

Die Frage ist, wie würden Sie diese Art von Veränderung einführen - wenn überhaupt?

Haftungsausschluss: Ich bin voreingenommen, als ich ein Buch über Polyglot-Programmierung auf der JVM (Shameless Plug !! - The Well-Grounded Java Developer) schreibe :)

Erstens sollten Sie die Änderung nur dort einführen, wo dies wirklich gerechtfertigt ist!

Ein guter Anfang ist die Betrachtung der Programmiersprachenpyramide von Ola Bini. Ola spricht über stabile, dynamische und domänenspezifische Sprachen.

Java ist eine stabile Sprache (statisch typisiert und verwaltet) und aus verschiedenen Gründen (ich kann später darauf eingehen, wenn Leute interessiert sind) keine ideale Wahl für dynamische Layer-Projekte (z. B. Rapid Web Development) oder domänenspezifische Layer-Projekte (z. B. Modellierung) die Enterprise Integration Pattern-Domäne). Wenn Sie ein Projekt haben, das in eine dieser Ebenen passt, kann dies ein guter Anfang sein.

Sie können auch eine neue Sprache auf der stabilen Ebene einführen, um Java zu ersetzen, wenn die alternative Sprache eine grundlegende Funktion bietet. Zum Beispiel behandelt Scala die Parallelität einfach sicherer und natürlicher als Java.

Wie gewünscht, noch etwas dazu. WRT Java:

• Die Neukompilierung ist mühsam
• Statische Typisierung kann unflexibel sein und zu langen Refactoring-Zeiten führen
• Die Bereitstellung ist ein schwerer Prozess
• Die Syntax von Java eignet sich nicht für die Erstellung von DSLs

An dieser Stelle fragen Sie sich möglicherweise: „Welche Art von Programmierherausforderungen passen in diese Ebenen? Welche Sprache (n) soll ich wählen? “, Denken Sie daran, dass es keine Silberkugel gibt, aber ich habe einige Kriterien, die Sie bei der Bewertung Ihrer Auswahl berücksichtigen könnten.

Domain-spezifisch

• Erstellen / Kontinuierliche Integration / Kontinuierliche Bereitstellung
• Dev-ops
• Modellierung von Unternehmensintegrationsmustern
• Modellierung von Geschäftsregeln

Dynamisch

• Schnelle Webentwicklung
• Prototyp entwickeln
• Interaktive Administrations- / Benutzerkonsolen
• Skripting
• Testgesteuerte Entwicklung / Verhaltensgesteuerte Entwicklung

Stabil

• Gleichzeitiger Code
• Anwendungsbehälter
• Kerngeschäftsfunktionalität

Beginnen Sie mit einem kleinen Modul mit geringem Risiko (denken Sie daran, dass diese JVM-Sprachen häufig wunderbar mit vorhandenem Java-Code interagieren) oder einem Projekt. Machen Sie deutlich, dass dies ein Wegwerfprototyp sein wird.

Stellen Sie sicher, dass Sie den Programmierlebenszyklus und die Werkzeugaspekte für diese Sprache untersucht haben. Sie sollten sicherstellen, dass Sie TDD können, Build-Tools und Continuous Integration ausführen, leistungsstarke IDE-Unterstützung und all diese anderen Faktoren haben. Für einige Sprachen müssen Sie nur akzeptieren, dass bestimmte Werkzeuge nicht vorhanden oder sehr einfach sind. Die Stärke des Entwicklers und die Werkzeugunterstützung können die Stärke einer Sprache überwiegen.

Stellen Sie sicher, dass es eine lebendige Community gibt, die Ihrem Team helfen kann, wenn es nicht weiterkommt. Lokale Benutzergruppen sind dafür noch besser.

Stellen Sie sicher, dass die Entwickler das erste Sprachtraining erhalten, insbesondere wenn die Sprache keine Sprache im OO-Stil ist (der Wechsel zu Clojure ist nicht trivial).

Das war's auch schon, denke ich. Ich persönlich habe Groovy, Scala und Clojure in meiner Entwicklung zusammen mit Java erfolgreich für Aufgaben wie XML-Verarbeitung, Erstellung schneller Websites und Datenverarbeitung verwendet.

Ich möchte einige Gedanken zu dem Thema hinzufügen, das mit der Bemerkung "wenn überhaupt" angesprochen wurde. Warum sollte man dem Team zusätzliche Sprachen vorstellen? Wenn Sie sich nur ein einzelnes Projekt ansehen, ist die neue Sprache möglicherweise das ideale Werkzeug für diese Aufgabe. Wenn Sie jedoch viele Projekte haben, werden Sie im Laufe der Zeit möglicherweise einige zusätzliche Sprachen haben. Ich weiß nichts über Ihre Wartungszyklen und Projektnummern, aber es besteht die Möglichkeit, dass das Team eine Menge Fachwissen in mehr Sprachen als zuvor bereitstellen muss.

Aus geschäftlicher Sicht bedeutet das Hinzufügen von Sprachen, dass dem Team Komplexität und Wissensanforderungen hinzugefügt werden. Dies verlängert die Zeiträume beruflicher Anpassungen, erschwert den (oder dauerhaften) Ersatz von Spezialisten in Ihrem Team im Urlaub und erfordert zusätzliche Schulungen für Teammitglieder, was kurzfristig zu einer Verlangsamung führt.

In meinen Augen sollte eine Strategie zur Begrüßung der Einführung solche Probleme neben rein funktionalen Aspekten auch ansprechen. Ist der erwartete Gewinn den zusätzlichen Aufwand und die Nachteile wie die oben genannten wert? Wenn dies nachgewiesen werden kann, können die Akzeptanzraten viel höher sein. Es könnte auch hilfreich sein, auf diese netten Investitionen in die Qualifikation der Teammitglieder hinzuweisen.

Ich würde sagen, fang an den Rändern an. Zeigen Sie die Sprache in nicht produktivem Code wie Build-Skripten, Maven-Plugins, Berichterstellung usw. Sobald sie den Nutzen und die Einfachheit erkannt haben, sind sie möglicherweise eher geneigt, kleine Projekte usw. zuzulassen.