Softwareentwicklung: Vor- und Nachteile von Polyglot-Artefakten

Softwareentwicklung: Vor- und Nachteile von Polyglot-Artefakten

In manchen Szenarien macht es in der Softwareentwicklung Sinn ein Entwicklungsartefakt in Form von einem Polyglot umzusetzen. Grundsätzlich bezeichnet man ein Artefakt, dessen Funktionalität in mehreren Programmiersprachen analog umgesetzt wurde als Polyglot. Es können aber auch nur einzelne Teile der gleichen Funktionalität in verschiedenen Programmiersprachen sein, die ein Artefakt zu einem Polyglot machen.
Polyglot-Artefakte sind aufwendig in der Pflege, können aber auch mit Vorteilen wie größerer Interoperabilität punkten. Die nachfolgende Ausführung soll die Vor- und Nachteile von Polyglot-Artefakte aufzeigen.
Die Betrachtung soll sich auf Polyglot-Programmbibliotheken beziehen, um einen festen Rahmen aufzuspannen, kann jedoch auf andere Szenarien transferiert werden. Es wird der komplette Entwicklungszyklus des Artefakts beleuchtet.
Vorweg: Einen hohen Wert sollte man meiner Meinung nach in der Polyglot-Entwicklung auf die von mir als Brückentechnologien bezeichnet legen. Brückentechnologien können die einzelnen Polyglot-Varianten ineinander aufgehen und verschmelzen lassen. Beispiele hierfür sind Standards wie HTTP, die von vielen unterschiedlichen Programmiersprachen unterstützt werden und nach außen hin eine völlig gleiche Funktionalität schaffen können.

Begriffsdefinitionen

  • Polyglot-Funktionalität: beschreibt allgemein die Funktionalität, die von einem Polyglot abgedeckt werden soll.
  • Polyglot-Variante: eine Variante ist eine Umsetzung der Polyglot-Funktionalität in einer bestimmten Programmiersprache

Vorteile

  • bei polyglotten Programmbibliotheken können mehr Anwender/Entwickler erreicht werden: viele Entwickler bevorzugen Programmiersprachen bei denen eine höhere Affinität vorliegt – ein Polyglot kann damit Hemmnisse bzgl. der unterstützten Programmiersprache verringern
  • mehr Freiheit bei der Auswahl der Zielplattform: die Auswahl der Ziellaufzeitumgebung wird flexibler durch die steigende Anzahl der Umsetzungen
  • Förderung des Austauschs zwischen Entwicklern mit Kenntnissen verschiedener Programmiersprachen
  • KnowHow über Funktionalität verschiedener Varianten muss nur für eine Variante erlernt werden. Danach kann das KnowHow auf die anderen Varianten einfach übertragen werden
  • Ab einer bestimmten Integrationsstufe können Tests wiederverwendet werden – hier wird jedoch eine Brückentechnolgie notwendig, die den Polyglot ineinander aufgehen lässt, allgemeine Standards: Beispiel http

Nachteile

  • vergrößerter Entwicklungs- und Wartungsaufwand durch verschiedene Codebases
  • die Anforderungen an den einzelnen Entwickler steigen verschiedene Sprachen zu beherschen
  • nicht alle Sprachkonstrukte sind von allen Sprachen unterstützt
    • Gegensteuern: nur ein Basisset von Sprachkonstrukten nutzen
  • der Buildvorgang wird aufwendiger
  • Gefahr dass die einzelnen Polyglot-Varianten in ihrer Funktionalität auseinander laufen
  • höherer Abstimmungsaufwand zwischen Entwicklern, wenn die verschiedenen Varianten von unterschiedlichen Entwicklern oder sogar unterschiedlichen Entwicklungsteams umgesetzt werden
  • Tests im Unit-Bereich müssen mehrfach gepflegt werden

Wie kann man den Nachteilen begegnen?

  • Strikte Prozessdefintion des Entwicklungsprozesses; z.B.: jede Variante setzt die Funktionalität auf die gleiche Art und Weise um. Es wird keine Funktionalität in den Hauptentwicklungszweig integriert bevor nicht alle Varianten auf dem gleichen Stand sind.
  • Transpiling: durch das Transpilieren einer Programmiersprache, kann eine Polyglot-Variante als Basis genutzt werden. Alle anderen Polyglot-Varianten werden von dieser Variante dann erzeugt. Somit wird die Gefahr verringert, dass die unterschiedlichen Polyglot-Varianten auseinander laufen. Definierte Konventionen, können ein Transpiling vereinfachen,z.B.:
    • nur ein Basisset von Sprachkonstrukten nutzen
    • Sprachkonstrukte die in anderen Sprachen fehlen durch Konventionen nachstellen (Beispiel: Fehlende Enums durch eine Liste von Konstanten kompensieren und beim setzen eines Wertes prüfen, ob die Konstantenliste diesen Wert enthält) – im Zusammenhang mit verschiedenen javascript-Dialekten von Browsern werden solche Mechanismen auch Polyfill genannt
  • Abstrahierung und Standardisierung der Buildprozesse: diese können zum einen die Sicherstellung des regelmäßiges Transpiling vereinfachen, als auch die Einhaltung einer strikten Prozessdefinition vereinfachen

    Kurzfristige mögliche Folgen

    • kleinere Iterationen innerhalb gleicher Entwicklungszeit möglich
    • größere Nutzerkreise

    Langfristige mögliche Folge beim verstärkten Einsatz von Polygloten

    Verringerung der Segmentierung unterschiedlicher Entwicklungsartefakte: mithilfe einer Brückentechnologie kann erreicht werden, dass die Interoperabilität zwischen den einzelnen Varianten gegeben ist. Somit können die Artefakte ab einem bestimmten Abstraktionslevel bis zu einem gewissen Grad verschmelzen.

    Fazit

    In vielen Fällen mag die Notwendigkeit eines Polyglots nicht gegeben sein. Grundsätzlich sollte man sich anhand von den Vorteilen, die ein Polyglot mit sich bringt überlegen, ob man diese für sein aktuelles Projekt benötigt und mit den Nachteilen die man sich einkauft leben kann.

    Weiterführende Links

    http://st.inf.tu-dresden.de/MRT08/papers/MRT08_manuscript18.pdf
    https://www.heise.de/developer/artikel/Warum-Polyglot-Programming-nicht-praxistauglich-ist-1479542.html

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

    %d Bloggern gefällt das: