Ubiquitous Language in einer nicht-englischen Fachdomäne: Unsere Herangehensweise

Wir haben in den vergangenen 20 Jahren verschiedene Ansätze verfolgt, mit Sprache im Projekt umzugehen. Manche haben sich bewährt, bei anderen sind wir auf Probleme gestoßen.

Da die Entscheidung für eine bestimmte Sprache bei der Begriffswahl im Domänenmodell eine lange Lebensdauer und weitreichende Auswirkungen hat, war es uns wichtig, im Team darüber Konsens herzustellen und eine für alle verbindliche Regelung zu finden.

Dieser Beitrag aus unserem Firmenwiki dokumentiert unsere Besprechungsergebnisse. 

Sprachwahl in Code, Kommentaren, Commits und Dokumentation

Für uns ging es um die Frage, ob wir als Sprache Englisch oder Deutsch wählen. Wie wir schnell gemerkt haben, hat dazu jeder starke persönliche Gewohnheiten und Präferenzen.

Daraus sollen aber keine weitergehenden Festlegungen folgen. So bedeutet eine Entscheidung für Deutsch nicht, dass wir nicht in Zukunft auch nicht-Deutsch-Muttersprachler beschäftigen können. Wenn sich die Rahmenbedingungen ändern (z. B. andere Team-Zusammensetzung, remote teams?) müssen wir das Thema erneut besprechen.

Leider gibt es keine scharfen Regeln, die in allen Fällen eine eindeutige Entscheidung ermöglichen. Wir haben aber gemerkt, dass sich Code, Kommentare, Commit Messages und Dokumentation u. U. an unterschiedliche Zielgruppen richten, was auch zu jeweils unterschiedlichen Entscheidungen führen kann.

Grundsätzliches

Die Sprachwahl ist ein wichtiges Thema: Das Prinzip der "Ubiquitous Language" bedeutet, eine alles durchdringende Sprache zu verwenden, und zwar von der fachlichen Diskussion und Analyse mit dem Kunden bis in den Code. Fachbegriffe der Domäne finden sich wörtlich im Code wieder.

Weder sollten fachliche Konzepte auf anders strukturierte technische Zusammenhänge "mental abgebildet" werden müssen, noch sollte es eine Übersetzung fachlicher Begriffe z. B. vom Deutschen in englische Begriffe geben, die dann im Code stehen.

Als Grundprinzip haben wir formuliert:

Wir wählen die Sprache so, dass wir die Notwendigkeit mentaler Transferleistungen (z. B. Übersetzungen) minimieren. 

Damit beugen wir Missverständnissen vor und reduzieren beispielsweise auch den Bedarf für ein Projekt-Glossar oder -Wörterbuch.

In unserer aktuellen Team-Zusammensetzung ist die Muttersprache für alle Mitarbeiter deutsch. Es ist daher auch die Sprache, in der wir sprachliche Nuancen und Bedeutungsunterschiede am besten beurteilen und Begriffe gezielt wählen können. Wenn wir uns in Englisch ausdrücken, bemerken wir unter Umständen gar nicht, welche Ungenauigkeiten oder Mehrdeutigkeiten wir damit für einen Muttersprachler erzeugen. 

Sprache im Programmcode

Alle Begriffe, insbesondere in Domänen-spezifischen Teilen des Codes, halten wir in der Sprache, die wir auch mit dem Kunden sprechen.

Schwierig könnte es dann sein, wenn der Kunde selbst international aufgestellt ist und evtl. intern mehrere Sprachen nutzt. Dann achten wir darauf, uns mit dem Kunden ggf. auf englische (= internationale?) Begriffe für fachliche Konzepte zu einigen. Diese Begriffe verwenden wir dann auch, wenn wir eine deutsche Unterhaltung führen. 

Es könnte hilfreich sein, diese Entscheidung einmal bewusst zu Beginn eines Projekts in einer Art "Charta" festzuhalten. Es ist dann fast weniger wichtig, welche Sprache festgelegt wird, als dass es überhaupt eine bewusste und dokumentierte Entscheidung gibt und diese auch von allen Beteiligten (Kunden und Entwicklern) gelebt wird.

Wenn wir Code schreiben, den wir quelloffen anbieten, haben wir in der Regel ein internationales (Fach-)Publikum. Dann gilt:

Veröffentlichter open source code nutzt Englisch als Sprache – es sei denn, er ist auf eine nicht-englische Fachdomäne ausgerichtet.

Eine weitere Regel, die direkt aus dem Prinzip der ubiquitous language folgt, ist:

Sprache und Begriffe werden in allen Code-Bereichen, d. h. in PHP, Twig, JavaScript, CSS etc. einheitlich genutzt.

Als Beispiel ist es ist nicht gut, eine View  suchergebnis.html.twig anzulegen und darin dann die CSS-Klasse  search-result einzuführen.

Auf der anderen Seite bringen Frameworks, Tools, Patterns etc. Begriffe und Konzepte mit, die typischerweise englisch benannt sind. Weil wir auch hier mentale Transferleistungen vermeiden wollen – nur eben anders herum – gilt:

"Stehende Begriffe" und Konventionen der Frameworks etc. bleiben erhalten. Beispiele sind  get...() ,  set...() ,  ...Controller ,  ...Factory ,  ...FormType  oder übliche Dinge wie  click(), toggle(), submit() .

Vielleicht kann man sagen, dass Englisch als Sprache im Code um so passender ist, je näher wir an der "Infrastruktur"-Schicht sind. 

Dokumentation

Für Dokumentation, die maßgeblich dazu gedacht ist, mit dem Kunden geteilt zu werden, gilt das gleiche Prinzip: Wir halten sie in der Sprache, die wir auch mit dem Kunden sprechen.

Sprache in Kommentaren, Commit Messages und Readme-Dateien

Kommentare, Commit Messages, Readme-Dateien etc. sind im Prinzip zeitlich versetzt vorgetragene Erklärungen an Kollegen oder unser zukünftiges Selbst.

Daher sollten sie um so mehr in der Sprache verfasst sein, die wir mit der entsprechenden Person auch sprechen würden.

Schreibe den Kommentar so, wie du ihn jetzt auch laut deinen Kollegen am Schreibtisch gegenüber vortragen würdest.

Der Unterschied zum Code ist also, dass wir Begriffe aus dem Code mit dem Kunden gemeinsam nutzen, während Kommentare etc. vor allem Notizen für uns selbst sind.

Aber auch hier gilt wieder: In Open Source-Projekten schreiben wir Englisch.

Schlussbemerkung

Uns war bewusst, dass diese starke Festlegung auf Deutsch Kosten verschiedener Art nach sich ziehen kann, wenn es irgendwann nicht mehr die selbstverständliche Sprachwahl unseres Entwicklungsteams sein sollte.

Allerdings macht es keinen Sinn, deshalb jetzt schon mögliche Probleme wie eine unklarere Ausdrucksweise, Bedeutungsverluste bei der Übersetzung etc. einzugehen, um das in Zukunft zu vermeiden.

Außerdem wird vermutlich jeder fremdsprachliche Entwickler zumindest so viel Deutschkenntnisse mitbringen müssen, dass er (oder sie) die Schlüsselbegriffe einer Domäne verstehen kann – und damit ist das Problem nicht "schlimmer", als eine englische Begriffswahl heute für uns wäre.