baydev
Published on

Ubiquitous Language und Denglisch

Authors
  • avatar
    Name
    Ismail Bay
    Twitter

Die Ubiquitous Language (allgegenwärtige Sprache) ist ein zentraler Bestandteil des Domain-Driven Design (DDD)1 Ansatzes in der Softwareentwicklung. Sie sorgt dafür, dass von Fachexperten bis hin zu Softwareentwicklern im gesamten Team die gleiche Sprache gesprochen und auch geschrieben wird.

Die Domäne gibt die Sprache vor

Je nach Branche kann die domänenspezifische Sprache eine höhere Komplexität aufweisen. In manchen Domänen wird man es schaffen, eine leicht verständliche Übersetzung im Code zu verwenden.

Andere Domänen wiederum verwenden im beruflichen Alltag eine Sprache, die Außenstehenden manchmal sogar wie eine Fremdsprache vorkommt. Macht es dann Sinn, diese Begriffe auf Biegen und Brechen zu übersetzen, um den Code auf Englisch halten zu können?

Aus Erfahrung kann ich sagen, dass dies in vielen Fällen, z.B. im Bauwesen, eher kontraproduktiv ist und schlussendlich den Code erst recht in eine unverständliche Sprache überführt.

Die fachlichen Begriffe im Bauwesen sind sogar auf Deutsch eine Herausforderung für branchenfremde Menschen. Oder versteht jeder sofort, was ein Leistungsverzeichnis2 ist? Schafft man dann im Projekt einen Mehrwert, wenn der Code Englisch bleibt und die notwendige Klasse BillOfQuantities3 benannt wird?

Länder- und branchenspezifische Begriffe

Ein Begriff kann sogar je nach Land, trotz gemeinsamer Sprache, eine andere Bedeutung annehmen. Als Beispiel betrachten wir den Begriff Vergabeplan. Im Allgemeinen wird man Folgendes darunter verstehen:

BrancheDeutschlandÖsterreich
BauwesenPlanung der Vergabe von Bauaufträgenaktualisierter Zustand des Bestandsplans zur Vorlage an Mieter, wird eher von großen Bauträgern wie Genossenschaften verwendet
anderePlanung einer öffentlichen VergabePlanung einer öffentlichen Vergabe

DINs bzw. ÖNORMen können auch für eine gemeinsame Sprache sorgen. Sie legen Standards in verschiedenen Branchen fest und sorgen dafür, dass Produkte und Dienstleistungen bestimmten Kriterien entsprechen.

Die Normdatenbank beinhaltet über 100.000 Dokumente. Fast für jede Branche gibt es abgenommene Normen für immer wiederkehrende Probleme.

Insbesondere im öffentlichen Sektor ist es oft unumgänglich, sich an die Normen zu halten. Warum dann nicht deren Sprache verwenden?

Auch im Alltag werden wir unbemerkt von vielen Normen begleitet: Nutzen im Alltag

Muss ich nun auf Deutsch programmieren?

Etablierte Begriffe und Konventionen können - und sollten auch - erhalten bleiben. Als Entwickler brauchen wir keine hohe mentale Leistung, um die Begriffe wie Controller, Decorator, fetch, usw. verstehen zu können.

Je mehr man die Grenze der fachlichen Domäne verlässt und in rein technischen Sphären unterwegs ist, wird Englisch als Sprache im Code passender.

Denglisch

Es gibt keine eindeutige Antwort darauf, ob man nur auf Englisch programmieren sollte. Das Sprachgefühl ist in der Muttersprache oft besser, aber in internationalen Teams, bei Open-Source-Projekten und im Austausch mit der Community ist Englisch von Vorteil.

Zudem variiert die Wahl der Sprache stark je nach Fachgebiet.

In unserer Branche reden wir Entwickler ständig Denglisch. Wir erstellen "Proof of Concepts" und keine "Machbarkeitsstudien", speichern unsere Daten in der "Cloud" und nicht in der "Wolke", "committen" oft und "pushen" täglich, schicken ein "Feature" zum "Code review" und "switchen" zurück zum "main Branch".

resistence is futile

Ubiquitous Language verhindert Missverständnisse, minimiert den Aufwand an mentaler Leistung für Übersetzungen. Wenn es im Projekt Sinn macht, kann auch eine gemischte Form der Sprachen für Kunden und Entwickler nützlich sein.

So hätten wir dann Klassen wie BestandsplanEventHandler und Events wie BestandsplanCreated und BestandsplanSigned.

Auf den ersten Blick mag das furchtbar aussehen. Es ist aber mit wenig mentaler Leistung ersichtlich, was die Klassen darstellen.

Footnotes

  1. https://martinfowler.com/bliki/UbiquitousLanguage.html

  2. https://de.wikipedia.org/wiki/Leistungsverzeichnis

  3. https://en.wikipedia.org/wiki/Bill_of_quantities