Der Reise-Butler ist die Smartphone-App für den wissbegierigen Reisenden und Fallbeispiel für die Methode CARDS+.


Die Pause ist noch nicht zu Ende, aber Moritz ist schon zurück im Besprechungsraum. Er will die Zeit nutzen, um das Fachklassenmodell für die Fahrt anhand seiner Notizen vollständig zu zeichnen. Beim Fahrtmodell möchte er mit dem Team nicht diskutieren. Er sieht sich hier als Experte der Domäne mit mehr als 10 Jahren Erfahrung, die er in mehreren Projekten der Deutschen Bahn gesammelt hat.

Langsam trudeln alle Teammitglieder ein. Moritz stellt die Stoppuhr auf 50 Minuten. Nachdem er die volle Aufmerksamkeit hat, wiederholt er seinen Standpunkt bezüglich des Fahrtmodells: « Ich bin fest davon überzeugt, dass wir mit dem abschnittbezogenen Modell die richtige Wahl treffen. Wir können damit Fahrten aller Verkehrsmittel abbilden. Wir bleiben offen für zusätzliche Daten, die wir auf dem Weg zwischen zwei Halten sammeln. Eine Fahrt hat mindestens einen Abschnitt und damit mindestens eine Abfahrt am Starthalt und eine Ankunft am Zielhalt. »

Moritz blickt in die Runde. « Ist das okay für euch? », fragt er.

Alle nicken.

Plötzlich hebt Tim die Hand. Er stellt eine Frage: « Das Modell ist voll in Ordnung. Ich vertraue da deiner Erfahrung. Du hast auch gesagt, dass es jetzt um ein Verständnismodell geht, dass nicht zwingend eins zu eins umgesetzt werden muss. Richtig? »

« Richtig », antwortet Moritz.

Tim fragt weiter: « Dann können wir bei der Implementierung doch sicher englische Begriffe verwenden. Ich meine z.B. “train” für Zug, “traveller” für Fahrgast, und so weiter. »

Moritz ist überrascht: « Warum willst du die Begriffe übersetzen? »

« Na, weil so ein Sprachenmix von deutsch und englisch einfach schrecklich ausschaut. Mit deutschen Begriffen hätten wir Getter wie “getFahrt” oder “getReise”. Da klingt doch “getTrain” viel besser. Das liest sich flüssiger », argumentiert Tim.

Moritz blickt wieder in die Runde: « Seht ihr das auch so? »

Kurzes Schweigen. Sie denken nach. Julius ist der erste, der etwas sagt: « Mir ist es eigentlich egal, wie die Klassen heißen. Bis jetzt war es immer englisch. Aber ehrlich, ich hab mir noch nie den Kopf darüber zerbrochen, ob das richtig oder falsch ist. »

Anne und Richard äußern sich ähnlich.

Georg sagt gar nichts.

« Ich habe zu diesem Punkt eine andere Meinung », sagt Moritz. « Machen wir doch einen Versuch. Nehmen wir z.B. den Begriff Fahrt, oder noch besser Zugfahrt. Wie würdet ihr den Begriff übersetzen? »

Von Tim kommt die Antwort wie aus der Pistole geschossen: «”train trip”, ganz klar. »

« Leider nicht”, antwortet Moritz, « Das wäre eher eine Übersetzung für Zugreise. Der Begriff Zugfahrt läßt sich mit »train ride« oder »train run« übersetzen. Der Unterschied ist, dass »train ride« die Zugfahrt aus Sicht eines Reisenden ist, während »train run« die betriebliche Sicht darstellt. Ihr seht, eine Übersetzung ist nicht immer eindeutig. Und ich habe noch ein Beispiel. Das Englische kennt keine Unterscheidung zwischen dem Halt, also der Tatsache, dass ein Fahrzeug an einem Ort geplant stehen bleibt, und der Haltestelle, also einem Ort, an dem solche Halte stattfinden können. Beides heißt »stop«. Im ersten Beispiel haben wir das Problem, dass es mehr als eine mögliche Übersetzung gibt. Das zweite Beispiel ist das Gegenteil. Für zwei unterschiedliche Begriffe gibt es die gleiche Übersetzung. »

Moritz sieht Tim an. « Verstehst du mein Problem mit der Übersetzung? »

Tim nickt. « So hab ich das noch nie gesehen”, sagt er. « Trotzdem ist es komisch, im Code deutsche Worte zu verwenden. »

« Ok, noch ein Argument. Ihr kennt doch “domain driven design”? »

Alle nicken. Richard antwortet: « Das sogenannte »domain driven design« ist ursprünglich eine Idee von Eric Evans. Die Modellierung der Software wird dabei maßgeblich von der Anwendungsdomäne beeinflusst. Das Modell hat unterschiedliche Elemente: “entity”, “aggregate”, “association”, “service”, “event”, “module”. Ganz wichtig ist noch der “bounded context”. Der Kontext beschreibt die Grenzen der Fachlichkeit. »

« Alles richtig, Richard. Einen Punkt möchte ich noch ergänzen. Beim Einsatz von “domain driven design” ist es ganz wichtig, dass bei der Modellierung eine gemeinsame Sprache entwickelt wird, die in allen Bereichen der Software-Entwicklung verwendet wird. Eine Übersetzung widerspricht doch diesem Ziel, oder? »

Nachdem niemand etwas erwidert, fährt Moritz fort: « Wir sind ein Team, jeder spricht perfekt deutsch. Der Reise-Butler wird hier, in Deutschland, entwickelt. Die Zielgruppe der App sind Nutzer in Deutschland. Ich frage mich, warum wir dann in einer fremden Sprache denken, schreiben oder programmieren sollen. »

Tim wagt sich noch einmal vor: « Und was ist, wenn der Reise-Butler so erfolgreich ist, dass er in ganz Europa eingesetzt wird? »

« Dann wird die Entwicklung immer noch in Deutschland stattfinden. Nur die App muss in mehrere Sprachen übersetzt werden. Der Code bleibt der Gleiche, Tim. Eine Fahrt ist auch in Frankreich eine Fahrt, genauso wie in England und Italien auch. Selbst für den Fall, dass es im Team jemanden gibt, der nicht mehr perfekt deutsch spricht, sehe ich kein Problem. In einem meiner Projekte der letzten Jahre gab es ein Offshore-Team in Indien. In dem Projekt wurden auch keine Begriffe übersetzt. Die Konzepte wurde übersetzt. Es gab regelmäßig einen Wissenstransfer, wenn neue Anforderungen umgesetzt wurden, mit “reverse presentation”. Wir konnten daher ganz gut beurteilen, ob die indischen Kollegen uns richtig verstanden haben. Sie hatten aber nie ein Problem mit Begriffen wie “Zug” oder “Fahrt” im Code. Für sie waren es einfach Worte aus der Domäne, die sie auch in ihren Präsentationen verwendet haben. Nur mit dem Plural der Begriffe konnten sie nichts anfangen. Sie kannten “Zug”, aber “Züge” war ein Problem, auch wegen dem Umlaut. »

Tim, mittlerweile durchaus fasziniert, fragt nach: « Aber beim Programmieren brauche ich häufig den Plural. Im Englischen hänge ich einfach ein Plural-s dran, in unserem Getter-Beispiel “getTrains”. »

« Ja, völlig richtig. Aber auch hier gibt es Ausnahmen. Das Wort “information” hat im Englischen keinen Plural. Nehmen wir an, du hast eine Liste von Informationen, dann hieße der Getter nach der Übersetzung im Code “getInformations”. Was aber rein sprachlich falsch wäre. »

« Okay. Ihr habt also Begriffe nicht übersetzt. Habt ihr dann “getZugList” verwendet, oder vielleich “getZugs”? », fragt Anne mit einem Anflug von Humor.

« Nein, unsere Lösung war anders. Wir haben bei Mengen einfach das Präfix »all« vorangestellt und weiterhin den Singular verwendet. In unserem Beispiel also “getAllZug”. Wir konnten dadurch den Plural vermeiden, alles war gut. »

An Anne gerichtet ergänzt Moritz: « Die Lösung mit »getZugList« haben wir nicht genommen, weil mit dem Suffix »List« ein bestimmter Typ, nämlich List, verbunden war. Das war eher irreführend bei einem Set oder einer Map. Und bei einer allgemeinen Collection ebenfalls. »

Die Stoppuhr schlägt Alarm. Die Zeit ist um. Moritz macht den Vorschlag, dass er die ganzen Regeln für die Verwendung der deutschen Begriffe im Code im Wiki zusammenfasst. Bei der nächsten Gelegenheit wollen sie die Regeln einmal diskutieren und einen gemeinsamen Vorschlag verabschieden.

Zuletzt veröffentlichte Beiträge: