Bezeichnungen in deutsch oder englisch?
-
Hustbaer schrieb:
Wie macht ihr es dann mit deutschen Fachbegriffen?
Alles auf Englisch bis auf die Fachbegriffe? Also "GetUmsatzView" und "CreateDispokreditBerechnungImpl"?Und habt ihr einen guten Richtwert/Faustregel wo man in solchen Fällen die Grenze ziehen sollte?
Und ... führt ihr - mehr oder weniger - verbindliche Listen von Fachbegriffen? Sonst passiert ja sowieso wieder das was Du (Sebastian) beschrieben hast: einer sagt so, der andere anders. Deutsche Fachbegriffe zu verwenden schützt ja nicht gegen z.B. Kellerspeicher vs. Stapelspeicher.
Was gefällt Dir nicht an "CreateDispokreditBerechnungImpl"? Es ist reine Gewohnheit. Würdest Du es immer machen, würde es Dir nicht mal mehr auffallen.
Zu der Grenze: es gibt - naja, sollte - irgendwo eine Grenze zwischen dem Kundenmodell geben, also den berühmten Domainenklassen, und der eigentlichen Implementation. Diese Ebene bietet sich doch an. Das oberste Modell ist dann in der Kundensprache, auch Workflows, Begriffe und Interaktionen sind dann in der Kundensprache. Damit ideal testbar, für den Kunden verständlich und diskutierbar, Tester und Dokumentation freuen sich auch darüber.
Hält man das zu 90% durch dürfte eine gute Trennung gelingen. 100% sind zwar ein tolles Ziel, der Aufwand ist aber oftmals diesen "Resterfolg" nicht Wert.
Daher dürfte es auch nicht zu so einem Konflikt kommen, daß jemand Daten auf dem Kellerspeicher ablegt, die Programmierer sprechen vom Stack, und auf Kundenebene ist das ja einfach nur ein "KundenVorgangsstapel".
Zu den Begriffen: in jedem Projekt sollte es ohnehin ein Glossar der Begriffe geben, allerdings ist das nach meiner Erfahrung oft so, daß die schlimmsten und übelsten Dinge zu Beginn da mal verzeichnet werden - denn über diesen Begriff waren alle Leute erstaunt - aber er deckt nicht 100% der Begriffe ab und wurde irgendwann nicht mehr gepflegt. Das macht nämlich verdammt viel Mühe das zu führen, und es macht noch mehr Mühe den ganzen Leuten im Team die Begriffe in den Kopf zu prügeln ("hey, es gibt eine neue Version vom Glossar, bitte auswendig lernen bis zum X.Y.!")
-
+1 für die Leute, die Deutsch in sinnvollen Fällen benutzen.
Eine Faustregel wie IMMER Englisch ist sinnfrei.
-
this->that schrieb:
Eine Faustregel wie IMMER Englisch ist sinnfrei.
Ja, ich halte das eher für eine Richtlinie, wobei ich, wenn ich die Wahl habe, eigentlich immer Englisch arbeite (schliesst auch Kommentar ein). Im Fall der Fälle zwanghaft etwas übersetzen zu wollen artet aber meistens in diesen grauenhaften Wortvergewaltigungen aus, die bei Informatikern bereits oft genug vorkommen. Das sollte man gefälligst lassen.
Wir hatten bei grossen Projekten bei wichtigen Kunden zum Glück meistens Fachidioten, die uns sehr genau sagen konnten, wie wir die Dinge im Englischen nennen sollen. Gerade im Finanz- und Bankensektor ist es doch unmöglich, dass man sich als Informatiker ohne solche Begleitung durch die Projekte kämpfen muss, da man die Begriffe gar nicht kennen kann, wenn man nicht wirklich damit arbeitet.
Meine Favoriten sind natürlich diese Buzz-Begriffe wie "Merchant Transaction Consolidation ID" welche sich inklusive Berücksichtigung spezieller Notationen und Abkürzungen (à la "
unser_praefix_kunden_praefix_merchant_trx_consolidation_id_beliebige_nummer") durch den Quelltext ziehen - und dann für etwas völlig anderes gebraucht werden, als der Name suggeriert. Dann kommt man schon ins GrübelnMfG :xmas1:
-
this->that schrieb:
+1 für die Leute, die Deutsch in sinnvollen Fällen benutzen.
Eine Faustregel wie IMMER Englisch ist sinnfrei.Und ich halte es für kurzsichtige Kleinstaaterei. Argumentation siehe Draveres Beiträge. "Nein, unsere Software wird für alle Zeiten nur von Programmierern angesehen werden die Deutsch als Muttersprache haben. Wir werden sie niemals exportieren, niemals mit anderer Software kombinieren und niemals ausländische Programmierer einstellen". Das ist vielleicht bei einem privaten Hobbyprojekt noch realistisch aber sonst nicht.
Das Argument, dass es keine englischen Begriffe gäbe kann ich auch nicht gelten lassen. Wie unterhalten sich denn deutsche Bankkaufleute mit ausländischen Kollegen?
-
Da ich gerade Ferien habe kann ich ja mal auch noch meinen Senf dazugeben: ^^
Ich finde, dass man grundsätzlich Englisch verwenden sollte. Dieses Gemisch aus Deutsch und Englisch (Denglisch) ist erstens unschön und zweitens verstehen halt nicht alle Deutsch.
Der einzige Ort an dem aus meiner Sicht Deutsch sinnvoll sein kann ist in einem Deutschen Tutorial für Anfänger. Da kann es vielleicht von Vorteil sein, da es leicht ersichtlich ist für Anfänger welche Teile des Programms selber gemacht sind und welche von irgendwo sonst herkommen. (Ging zumindest mir teilweise so).
Aber sonst aus meiner Sicht IMMER Englisch verwenden. (Ich hatte gerade eine Vorlesung in diesem Semester, in der z.B. Subscriber zu Subskribent oder Publisher zu Herausgeber wurde ==> äusserst mühsam).
-
icarus2 schrieb:
(Ich hatte gerade eine Vorlesung in diesem Semester, in der z.B. Subscriber zu Subskribent oder Publisher zu Herausgeber wurde ==> äusserst mühsam).
Das Beispiel ist ziemlich sinnfrei, denn das ist ja genau da, wo man sich auf Bibliotheksebene bewegt... da tut das keinem Weh, was die Entwickler so anstellen.
-
icarus2 schrieb:
Dieses Gemisch aus Deutsch und Englisch (Denglisch) ist erstens unschön und zweitens verstehen halt nicht alle Deutsch.
Es verstehen auch nicht alle Englisch. Sie glauben es zwar, aber...
Noch besser wäre es ja mit einer französischen Firma zusammen zu arbeiten, und dann aus Gründen der Verständlichkeit alle Begriffe auf Englisch zu formulieren.
-
SeppJ schrieb:
Das Argument, dass es keine englischen Begriffe gäbe kann ich auch nicht gelten lassen. Wie unterhalten sich denn deutsche Bankkaufleute mit ausländischen Kollegen?
Es gibt nicht übersetzbare deutsche Fachterminologie, genauso wie im Deutschen englische Begriffe verwendet werden, weil wir keine eigenen entwickelt haben. Die Bereiche kann man sicherlich an einer Hand abzählen, aber es ist so. Der Bahnbereich ist ein gutes Beispiel. Bahn funktioniert in England, Frankreich, Deutschland und Amerika eben anders. Und im Rest der Welt so, wie in einem der Vorgenannten.
-
SeppJ schrieb:
Und ich halte es für kurzsichtige Kleinstaaterei. Argumentation siehe Draveres Beiträge. "Nein, unsere Software wird für alle Zeiten nur von Programmierern angesehen werden die Deutsch als Muttersprache haben. Wir werden sie niemals exportieren, niemals mit anderer Software kombinieren und niemals ausländische Programmierer einstellen".
Nochmal, solange dadurch der heute verkaufbare Wert des Produkts nicht erhöht wird - dieses Feature also nicht wertschöpfend ist - macht es keinen Sinn dafür Geld aufzuwenden. Wenn die berühmte User-Domain bereits englischsprachig ist, dann hat man Glück, und es fällt leicht alle Begriffe entsprechend zu behandeln. Aber wenn dem nicht der Fall ist muß man das bewerten - Argumentation in meiner Antwort an Dravere.
Aber für den Automatismus "es ist eleganter und könnte mal mehr Geld bringen" würde ich kein Geld spendieren.
-
Marc++us schrieb:
icarus2 schrieb:
Dieses Gemisch aus Deutsch und Englisch (Denglisch) ist erstens unschön und zweitens verstehen halt nicht alle Deutsch.
Es verstehen auch nicht alle Englisch. Sie glauben es zwar, aber...
Dann sind sie eben nicht qualifiziert, um gute Software zu entwickeln. Das ist dann genauso wie ein Programmierer der durch andere Stilfehler schlecht wartbaren Code schreibt. Da besteht meines erachtens nach kein großer Unterschied zwischen jemandem der Spagetthiode schreibt und jemandem der deutsche Bezeichner benutzt. Den Spagetticode kann dann nur ein Genie durchschauen, den deutschen Code nur jemand der Deutsch spricht. Der Unterschied ist bloß die unterschiedliche Anzahl von Deutschsprechern und Genies auf der Welt. Letztlich ist beides für große Teile der Weltbevölkerung unverständlich.
Gegenfrage: Wären Bezeichner auf chinesisch ok? Oder was ist wenn wir eine noch seltenere Sprache als Deutsch sprechen würden, z.B. baskisch. Ist es für einen baskischen Programmierer ok, baskische Bezeichner zu benutzen?
-
SeppJ schrieb:
Marc++us schrieb:
icarus2 schrieb:
Dieses Gemisch aus Deutsch und Englisch (Denglisch) ist erstens unschön und zweitens verstehen halt nicht alle Deutsch.
Es verstehen auch nicht alle Englisch. Sie glauben es zwar, aber...
Dann sind sie eben nicht qualifiziert, um gute Software zu entwickeln. Das ist dann genauso wie ein Programmierer der durch andere Stilfehler schlecht wartbaren Code schreibt. Da besteht meines erachtens nach kein großer Unterschied zwischen jemandem der Spagetthiode schreibt und jemandem der deutsche Bezeichner benutzt. Den Spagetticode kann dann nur ein Genie durchschauen, den deutschen Code nur jemand der Deutsch spricht. Der Unterschied ist bloß die unterschiedliche Anzahl von Deutschsprechern und Genies auf der Welt. Letztlich ist beides für große Teile der Weltbevölkerung unverständlich.
Gegenfrage: Wären Bezeichner auf chinesisch ok? Oder was ist wenn wir eine noch seltenere Sprache als Deutsch sprechen würden, z.B. baskisch. Ist es für einen baskischen Programmierer ok, baskische Bezeichner zu benutzen?
zieh dir doch mal php sourcecode rein, die erlauben ja unicode in bezeichnern. ich hab mich da gelegentlich schon ganz schön geärgert...
-
SeppJ schrieb:
Das Argument, dass es keine englischen Begriffe gäbe kann ich auch nicht gelten lassen. Wie unterhalten sich denn deutsche Bankkaufleute mit ausländischen Kollegen?
Wenn englische Banker (auch untereinander) über Pfandbriefe sprechen, reden sie von "pfandbriefs" oder "german pfandbriefs". Umgekehrt sprechen deutsche Banker von Gilt-Bonds oder auch einfach Gilts. Deutscher als "Gilt-Anleihe" wird's jedenfalls nicht. Das amerikanische Finanzministerium wird idR auch von deutschen Bankern schlicht als "US-Treasury" bezeichnet, und die Bundesbank wird auch in Amerika "German Bundesbank" genannt.
Die stehen nämlich vor genau dem selben Problem, und der Praktiker benutzt einfach den Namen weiter, den es schon gibt. Dass der nicht in der eigenen Landessprache ist, ist von untergeordneter Bedeutung.
-
SeppJ schrieb:
this->that schrieb:
+1 für die Leute, die Deutsch in sinnvollen Fällen benutzen.
Eine Faustregel wie IMMER Englisch ist sinnfrei.Und ich halte es für kurzsichtige Kleinstaaterei. Argumentation siehe Draveres Beiträge. "Nein, unsere Software wird für alle Zeiten nur von Programmierern angesehen werden die Deutsch als Muttersprache haben. Wir werden sie niemals exportieren, niemals mit anderer Software kombinieren und niemals ausländische Programmierer einstellen". Das ist vielleicht bei einem privaten Hobbyprojekt noch realistisch aber sonst nicht.
Das Argument, dass es keine englischen Begriffe gäbe kann ich auch nicht gelten lassen. Wie unterhalten sich denn deutsche Bankkaufleute mit ausländischen Kollegen?
-
this->that schrieb:
seldon hat doch gerade gesagt, wie die sich mit mit Engländern unterhalten. Wenn die Übersetzung von Pfandbrief eben pfandbrief ist, dann ist das etwas was man im Programm benutzen kann. Nur weil das dann im Englischen ein Lehnwort ist, ist es immer noch Englisch.
-
Ob man nicht übersetzbare Begriffe deutsch belässt oder sie mit ihrem identischen Lehnwort übersetzt, ist doch Erbsenzählerei.
-
Marc++us schrieb:
Nochmal, solange dadurch der heute verkaufbare Wert des Produkts nicht erhöht wird - dieses Feature also nicht wertschöpfend ist - macht es keinen Sinn dafür Geld aufzuwenden.
Das halte ich für ein typisches kurzsichtiges Managerdenken. Wenn man nicht auf dem Papier nachweisen kann, dass etwas sofort Gewinn abwirft, dann wird kein Geld investiert. Völliger Habakuk...
Es gibt zahlreiche Features, welche den heutigen verkaufbaren Wert nicht sofort erhöhen, aber dafür in der Zukunft riesen Summen einsparen können.
Dieses kurzsichtige Denken ist genau wie in der Politik mit Bauten umgegangen wird. Da wird mit heutigen Kapazitäten geplant und wenn dann in 10 Jahren die Verkehrsachse besteht, muss sie bereits wieder abgerissen und neugebaut werden. Wenn man dagegen vorausgeplant und ein wenig vorausgedacht hätte, hätte man riesige Summen einsparen können. Aber es hatte damals zu diesem Zeitpunkt halt keinen Mehrwert, also wird es ignoriert...Vorausdenken muss nicht PMO sein, sondern kann auch eine Risikoreduktion bedeuten, wofür es sich lohnen kann, Zeit/Geld zu investieren. Die Wertschöpfung muss nicht heute/morgen/übermorgen passieren, sondern kann auch erst in 5 Jahren auftauchen.
Klar, das heisst natürlich auch nicht, dass man es übertreiben muss. Ich habe es ja auch als Richtlinie gemeint. Aber halt ein wenig menschliches und vernünftiges Denken reinbringen, schadet sicher nicht, anstatt immer sturr nach irgendwelchen irreellen Zahlen zu rechnen. Wahrscheinlich nach Model XYZ, wobei eine Wertschöpfung auf 6 Nachkommastellen genau rauskommt, welche bereits nach einem Monat hinten und vorne nicht mehr stimmt.
Wozu sollen die Mitarbeiter glücklich sein? Der Automat darf keine gratis Snacks verteilen, das hat keinen Mehrwert für das Produkt. Eigene Büros? Kostet zuviel! Streichen wir alles, braucht es nicht, dafür haben wir nun auf dem Papier ein fettes Plus. Wir sind gut und schnappen uns den Bonus. Was in 5 bis 10 Jahren ist, obwohl gerade Software eigentlich sehr langlebig ist, kümmert uns einen alten Hut.
Die DB wird es dir auch danken, wenn deine Firma kaputt geht und die Software von einer anderen Firma (womöglich ausländischen?), übernommen und weitergewartet wird. Das könnte sogar noch zu einem Verkaufsargument werden, schliesslich geht die DB ein höheres Risiko ein, wenn die Software nur von deutschen Entwicklern gewartet werden kann.
... der Beitrag ist gerade ein wenig ein durcheinander, aber ich habe keine Lust mehr aufzuräumen. Dieser Satz, den ich in so manchen Formen nun schon gehört habe, ärgert mich einfach nur. Man hätte so viel Geld einsparen und so viele Probleme frühzeitig lösen können, wenn die Manager nicht nur auf das Papier geschaut hätten. Aber nein, man gibt lieber heute weniger aus, damit man dann morgen das 10-fache ausgeben kann, damit auch ja die aktuelle Bilanz schön aussieht.
Grüssli
-
Dravere schrieb:
Vorausdenken muss nicht PMO sein, sondern kann auch eine Risikoreduktion bedeuten, wofür es sich lohnen kann, Zeit/Geld zu investieren. Die Wertschöpfung muss nicht heute/morgen/übermorgen passieren, sondern kann auch erst in 5 Jahren auftauchen.
"Vorausdenken" kann das Risiko verringern, allerdings genau so auch erhöhen. Das Risiko dass ein Projekt den Bach runter geht, ist bei einem Projekt das mehr kostet, länger dauert und schwieriger zu entwickeln ist einfach höher.
Man muss - wie überall - die Vorteile gegen die Nachteile aufwiegen.
Da es glaube ich keine brauchbaren Zahlen zu dem Thema gibt, ist das natürlich nicht einfach, bzw. eine sehr subjektive Sache.Zu viele Dinge vorauszuplanen kann die Entwicklungszeit enorm verlängern, und das kann schnell mal das Aus für eine Firma bedeuten - ganz speziell Startups. Die Erfahrung zeigt auch recht deutlich, dass man heute schwer abschätzen kann, was man morgen brauchen wird, bzw. was Feature X morgen an Wert für die Firma bedeuten wird.
-
...... schrieb:
Ob man nicht übersetzbare Begriffe deutsch belässt oder sie mit ihrem identischen Lehnwort übersetzt, ist doch Erbsenzählerei.
Aber es passt zur Weihnacht
rucke di guck, rucke di gu ...;)
-
Marc++us schrieb:
Nochmal, solange dadurch der heute verkaufbare Wert des Produkts nicht erhöht wird - dieses Feature also nicht wertschöpfend ist - macht es keinen Sinn dafür Geld aufzuwenden.
Und darum wurden bei uns immer nur neue Features eingebaut, aber nie was refactored und jetzt ist die SW Müll und muss neu geschreiben werden.
-
Ich benutze selbstverständlich deutsch, weil mein Code weder internationl rumgereicht wird, noch weil ich Wert darauf lege meine Freunde beeindrucken zu wollen
Nebeneffekt von deutschen Bezeichnungen: man kann sie ganz eindeutig als eigene erkennen, statt sie mit vorgegebenen Namen zu verwechseln.
Die Empfehlungen für Englisch lassen praktisch immer ausser Acht, dass es sich bei 99% der Leute hier nicht um festangestellte Profiprogrammierer handelt, welche in internationalen Arbeitsgruppen tätig sind
Ich brings mal auf den Punkt: wer nicht international tätig ist, seine Kinder aber Justin, Cindy etc nennt, der nimmt natürlich englisch als Code-Begleitsprache, alles klar?
