// HEISE ONLINE — HARDWARE & GADGET
Deutsche Fachsprache, englischer Code: Wo verläuft die Grenze?
Die Begriffe an der Workshop-Wand sind deutsch, der Code ist englisch. Diesen Übergang entscheidet fast nie jemand bewusst, und genau das wird teuer.
This article is also available in
English.
It was translated with technical assistance and editorially reviewed before publication.
Am Ende eines Modellierungsworkshops sieht das dafür genutzte Whiteboard oft beeindruckend aus. Zettel in mehreren Farben kleben darauf, Pfeile dazwischen verweisen auf Zusammenhänge, und auf den Pfeilen stehen die Begriffe, um die drei Tage lang gerungen wurde: „Rechnungsstellung“, „Mahnlauf“, „Teilzahlung“, „Storno“. Die Fachabteilung nickt, die Entwicklerinnen und Entwickler nicken, und alle haben zum ersten Mal seit Monaten das Gefühl, über dieselbe Sache zu sprechen.
Eine Woche später öffne ich das Repository, und die erste Klasse heißt InvoiceService. Nicht aus Trotz, nicht nach einer Diskussion, sondern weil es sich beim Tippen so angefühlt hat, wie Code eben aussieht. Zwischen Whiteboard und Repository liegt eine Entscheidung, die niemand getroffen hat, und um die es in diesem Beitrag geht.
Ich halte diesen Reflex durchaus für nachvollziehbar. Immerhin: Alles, woraus Entwicklerinnen und Entwickler ihr Handwerk lernen, ist englisch: die Schlüsselwörter der Sprache, die Signaturen der Standardbibliothek, die Dokumentation der Frameworks, die Antworten auf Stack Overflow. Wer den ganzen Tag „for“, „return“ und „Repository“ liest, schreibt beim nächsten Bezeichner nicht plötzlich auf Deutsch weiter.
Dazu kommt ein Argument, das in jeder dieser Diskussionen fällt: die internationale Lesbarkeit. Wenn morgen jemand aus einem anderen Land ins Team kommt, soll der Code lesbar und verständlich bleiben. Das Argument ist nicht falsch, es ist nur in den meisten Fällen unbelegt, weil das betreffende Team seit acht Jahren aus denselben sechs Personen in derselben Stadt besteht und sämtliche Anforderungen seit jeher auf Deutsch bekommt.
Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.
Es gibt außerdem noch einen Grund, den allerdings kaum jemand ausspricht: Englisch im Code sieht nach Professionalität aus. Ein Bezeichner wie createInvoice wirkt wie Software, rechnungErstellen wirkt wie ein Provisorium aus dem Rechnungswesen. Dieses Gefühl ist unter Entwicklerinnen und Entwicklern durchaus real und verbreitet. Und zugleich ist es der schwächste aller Gründe, weil es über die Fachlichkeit rein gar nichts aussagt.
Vor allem aber gelten diese Gründe für die Technik. Dass HttpClient nicht HttpKlient heißen sollte, wird wohl niemand bestreiten, und ich persönlich möchte eine solche Umbenennung auch nicht. Der Reflex wird erst dort teuer, wo er auf Fachlichkeit trifft, und dieser Übergang ist so fließend, dass er im Alltag nicht auffällt.
Sobald das Thema nach der zu verwendenden (natürlichen) Sprache aufkommt, kippt die Diskussion üblicherweise binnen weniger Minuten in einen Streit über Geschmack. Jemand schreibt rechnungErstellen auf das Whiteboard, jemand anderes verzieht das Gesicht, und ab da geht es um Denglisch, um Umlaute in Bezeichnern und um die Frage, ob das nicht furchtbar aussehe. Genau diese Diskussion ist die Ursache dafür, dass sich an der Sprachfrage nie etwas ändert. Sie verbraucht die gesamte Aufmerksamkeit für den unwichtigsten Teil des Problems.