In welcher Sprache soll ich meine Businessklassen benennen?

Ich fordere Best Practice für diese Frage an. Dies ist nur dann ein Problem, wenn die Kundenfirma streng national ist und eine andere Muttersprache als Englisch hat, denke ich.

Wenn der Kunde viele hauptsächlich sehr domänenspezifische Ausdrücke hat, gemischt mit einigen weniger domänenspezifischen Bezeichnungen. Die Sprache unserer Codekommentare, Klassen- / Methoden- / Variablennamen ist Englisch. Würden Sie alle domänenspezifischen Namen übersetzen?

Ich arbeite in Deutschland und ziehe es vor, Englisch zu lernen.

Manchmal verwende ich zB domänenspezifische Dinge wie das Erstellen eines Moduls zu "DATEV" (deutsche Rechnung / Abrechnungssoftware) deutsche Namen. Einige deutsche Wörter können nicht richtig übersetzt werden, z. B. "Referenzbuchungsnummer" oder "Sachkontenlaenge". Ich denke auch, dass domänenspezifische Dinge in Wartungshorror enden würden. Vielleicht würden Sie sich daran erinnern, dass sich ReferenceBookingNum auf die Referenzbuchungsnummer bezieht, aber was ist mit Ihren Mitarbeitern? Sie müssen die interne Dokumentation über die Benennung studieren, falls eine Dokumentation vorhanden ist. Sie werden mit dem Modul nicht sehr vertraut sein, wenn sie keine richtigen Namen haben. Es ist eine unnötige Komplexität, wenn alle anderen Entwickler auch Deutsche sind. Aber "CakeFactory" klingt viel besser als "KeksFabrik";)

Es kommt also alles darauf an.

Als Norweger, der in einer norwegischen Firma arbeitet, benenne ich meine Objekte auf Englisch. Natürlich haben einige Wörter oder Konzepte möglicherweise kein Gegenstück zum Englischen, und in diesem Fall kann man argumentieren, dass ein Muttersprachler anstelle eines schlechten Ersatzes oder einer wörtlichen Übersetzung verwendet wird, die keine Bedeutung hat. Natürlich könnten viele dieser Probleme die Tatsache sein, dass einige von uns einen besseren Wortschatz haben sollten, deshalb frage ich normalerweise einen Kollegen, ob mir kein guter englischer Name einfällt :)

Einige unserer Mitarbeiter sind nicht norwegisch und können daher auch auf Englisch schreiben. Die Möglichkeit, Programmierer aus den meisten Teilen Europas einzustellen, ist für die Wirtschaft von Vorteil, sodass auch mein Unternehmen davon profitiert.

Übrigens: Ich erinnere mich, dass ich die Quelle von Hermes einmal gelesen habe (ebXML b2b-Implementierung) und es mir schwer gefallen wäre, wenn sie in Mandarin geschrieben und kommentiert hätten.

Ich glaube, da Englisch die Verkehrssprache der IT-Domäne ist, führt die Beschränkung Ihres Quellcodes auf eine andere Sprache zu künstlichen Hindernissen für dessen Entwicklung. Zunächst begrenzen Sie den Pool der Personen, die zu Personen beitragen können, die eine bestimmte Sprache sprechen. Der gleiche Grund, den Sie im Stapelaustausch und nicht auf einer lokalen Site gefragt haben.

Sie wissen auch nicht, woher die Beiträge kommen und wohin sie gehen. Was ist, wenn Sie ein Beispiel von einer Website verwenden, werden Sie das übersetzen? Was ist, wenn das Produkt erweitert wird, um von Kunden in einem anderen Land verwendet zu werden? Müssen Sie einen Auftragnehmer beauftragen / ein wenig auslagern? Warum auf einen Pool beschränken und nicht aus der ganzen Welt das Beste herausholen?

Kann davon ausgehen, dass es für einige domänenspezifische Strukturen in Ordnung ist, die sich nicht leicht auf andere Sprachen abbilden lassen, oder wenn eine vorhandene Codebasis beibehalten wird.

Mein letztes Projektziel war es, den Geschäftsbereich von Sicherheiten und Hypotheken zu modellieren. Alle Entwickler und die Firma, für die wir gearbeitet haben, kommen aus Polen. Wir haben die Software nach Domain Driven Design-Prinzipien entwickelt. Wir haben polnische Namen für alle Unternehmenseinheiten verwendet und ich denke, es war eine sehr gute Wahl. Ich denke, dass wir durch diesen Ansatz Kommunikationsprobleme vermeiden konnten. Der Geschäftsbereich bestand aus vielen Begriffen, die ich nicht einmal auf Polnisch kannte, ganz zu schweigen von englischen Übersetzungen. Wir verwendeten nur lateinische Buchstaben und alle technischen Klassen wurden auf Englisch benannt.

Es ist im Allgemeinen einfacher, in einer einzigen Sprache geschriebenen Quellcode zu lesen. Dies bedeutet für die meisten Programmiersprachen, dass Sie es auf Englisch schreiben sollten.

Das heißt, es gibt ein großes Problem mit Domain-Konzepten, die sich nicht leicht ins Englische übersetzen lassen. Ein typisches Beispiel ist eine eindeutige Kennung, die die Gesellschaft dem Einzelnen gibt. In den USA ist das nächstliegende Konzept die Sozialversicherungsnummer, es handelt sich jedoch nicht um eine genaue Zuordnung. Namen und Telefonnummern lassen sich normalerweise recht gut zuordnen.

Ich glaube, dass es normalerweise notwendig ist , die Domainbegriffe beizubehalten, wenn eine genaue Zuordnung nicht ohne weiteres auf Englisch verfügbar ist, sondern nur diese - den Rest auf Englisch. Dies führt zu ungewöhnlichen Bezeichnern wie KommuneImpl, sollte jedoch für diejenigen, die die Domäne kennen, sofort Sinn machen.

Open-Source / internationale Gemeinschaftsprojekte

Die gemeinsame Sprache von Open Source- und internationalen Community-Projekten ist Englisch. Beispiel: Die Sprache der Stack Exchange-Sites ist Englisch. Um die größtmögliche Zugänglichkeit zu gewährleisten, sollte für alle Code- und Objektnamen Englisch verwendet werden.

Kommerzielle Projekte

Die meisten internationalen Softwarefirmen schreiben den Code in Englisch vor. Es ist der größte gemeinsame Nenner, daher ist es sinnvoll, Englisch als Mittel zur Schaffung von Konsistenz zu verwenden.

Viele regionale Softwarefirmen schreiben in ihrer Muttersprache. Nicht alle folgen diesem Ansatz, aber es ist aus ihrer Sicht sinnvoll - sie verwenden die gemeinsame Sprache für alle ihre Entwickler.

Geschäftsobjekte benennen

Die Codierungssprache des Teams sollte verwendet werden, um Objekte zu benennen.
Die Entwickler müssen in erster Linie in der Lage sein, über die Objekte und die Projektanforderungen miteinander zu kommunizieren. Wenn das Team in Französisch schreibt, sollten die Geschäftsobjekte in Französisch benannt werden. Wenn sie in Englisch codieren, benennen Sie die Objekte in Englisch.

Ihre Frage fügt eine Falte hinzu, weil der Kunde eine andere Muttersprache spricht als die Programmiersprache Ihres Teams. Sie sollten weiterhin die Programmiersprache Ihres Teams verwenden, um die Objekte zu benennen.
Wenn die Geschäftsanalysten oder Entwickler mit dem Kunden über die spezifischen Geschäftsobjekte kommunizieren müssen, kann eine bedarfsgerechte Übersetzung des Objektnamens von der Codierungssprache in die Kundensprache erforderlich sein. Aus meiner Erfahrung ist es ziemlich selten, dass ich mit dem Client über bestimmte Codeobjekte gesprochen habe, sodass die Übersetzung zurück in die Client-Sprache nicht wirklich erforderlich war.

Die einzige Ausnahme von der Benennungsregel besteht darin, dass ein Objekt keinen anderen ausreichend präzisen Begriff hat, um die Absicht des Objekts zu erfassen. IMO, das ist wirklich selten, aber es kann vorkommen. In Wirklichkeit ist es jedoch dasselbe, was gesprochene Sprachen tun, um bestimmte Konzepte auszudrücken. " Facade " ist ursprünglich ein französischer Begriff, wurde jedoch vom Englischen angepasst, um das Konzept auszudrücken, und ist ein gängiges Entwurfsmuster. " Schadenfreude " ist ein weiteres gutes Beispiel für einen geliehenen Begriff, obwohl ich glaube, dass er kein entsprechendes Muster hat.