In quale lingua dovrei nominare le mie classi di attività?

29

Sto richiedendo le migliori pratiche con questa domanda. Questo è un problema solo se la società cliente è strettamente nazionale ha una lingua madre diversa dall'inglese, credo.

Se il cliente ha molte espressioni principalmente molto specifiche del dominio (diciamo, tedesco), mescolate con alcune denominazioni specifiche del dominio minori. La lingua dei nostri commenti sul codice, nomi di classi / metodi / variabili è l'inglese. Vuoi tradurre tutti i nomi specifici del dominio?

naming

— Zeemee
fonte

11

Inglese. Lingua francese per la programmazione.

— Rig

6

Uno dei 'impegnativi' i messaggi di errore più PHP ha un interessante tocco ebraico: unexpected T_PAAMAYIM_NEKUDOTAYIM. Avendolo visto alcune volte nella mia vita, non ho dubbi sul fatto che si debba usare l'inglese.

— K.Steff,

3

Alcune delle espressioni specifiche del dominio tedesco hanno caratteri non standard (diciamo, umulauts (sp?))? Se assumi programmatori al di fuori della tua regione, potrebbero non essere in grado di trovare una tastiera con i caratteri richiesti (il mio no). Sì, ci sono modi per cambiare la lingua "tipizzata", ma non vorrei che quella seccatura.

— Clockwork-Muse

2

Greco - l'uso di alfabeti non latini è una sicurezza del lavoro migliore rispetto a Klingon.

— Wyatt Barnett,

3

@ X-Zero andando fuori dalla semplice ASCII apre la "quale codifica dei caratteri utilizziamo" can dei worm. Di solito vieni morso e non ci vai più.

16

Sto lavorando in Germania e preferisco scegliere l'inglese.

A volte, ad esempio, cose specifiche del dominio come la creazione di un modulo in "DATEV" (software tedesco di fatturazione / fatturazione), utilizzo nomi tedeschi. Alcune parole tedesche non possono essere tradotte correttamente, ad esempio "Referenzbuchungsnummer" (ReferenceBookingNum?) O "Sachkontenlaenge" (..?). Inoltre penso che le cose specifiche del dominio finirebbero con l'orrore della manutenzione. Forse ricorderesti che ReferenceBookingNum si riferirebbe a "Referenzbuchungsnummer", ma per quanto riguarda i tuoi collaboratori? Devono studiare la documentazione interna sulla denominazione, se esiste la documentazione. Non avranno molta familiarità con il modulo senza avere nomi propri. È una complessità inutile se anche tutti gli altri sviluppatori sono tedeschi. Ma "CakeFactory" suona molto meglio di "KeksFabrik";)

Quindi tutto dipende.

— lurkerbelow
fonte

2

Questa risposta riflette maggiormente la mia opinione personale, dopo aver letto le altre risposte. Soprattutto questo punto: "È una complessità inutile se anche tutti gli altri sviluppatori sono tedeschi" quando traducono tutto.

— Zeemee,

1

@Mulmoth: "È una complessità superflua se anche tutti gli altri sviluppatori sono tedeschi" --- Come puoi essere sicuro che in un certo momento, in alcuni anni, il progetto non sarà esternalizzato in un altro paese? Come puoi essere sicuro che uno sviluppatore di lingua non tedesca non verrà introdotto nel progetto in un determinato momento?

— Coral Doe,

5

@Coral Doe - Penso che lo sviluppatore nuovo / altro / esternalista debba già scavare a fondo nel dominio aziendale e nelle sue espressioni specifiche. Quindi, è più facile mappare ciò che il cliente (che sarà ancora tedesco allora) dice alle classi nominate tedesche, invece di nomi inglesi tradotti male / erroneamente.

— Zeemee,

2

Le "cose" di fatturazione / imposte tedesche non saranno mai esternalizzate in un paese di lingua non tedesca. All'università qualcuno mi ha detto che l'85 percento di tutti i libri di fatturazione / tasse fa riferimento alle leggi tedesche e sono scritti in tedesco. In tutto il mondo.

— lurkerbelow,

3

Sono d'accordo, ma un problema che quasi sempre accade è che il linguaggio utilizzato dagli sviluppatori fuoriesce dagli utenti e dagli altri stakeholder. Non come parte dell'interfaccia utente ma come parli del dominio problematico. Ciò porterà inevitabilmente alla confusione in quanto non tutti parlano inglese fluentemente come la maggior parte degli sviluppatori.

— Mille Bessö,

14

Essendo norvegese che lavora in un'azienda norvegese, chiamo i miei oggetti in inglese. Naturalmente alcune parole o concetti potrebbero non avere una controparte inglese e in tal caso si potrebbe sostenere che una parola nativa potrebbe essere usata al posto di una sostituzione errata o di una traduzione letterale che non ha significato. Certo, molti di questi problemi potrebbero essere il fatto che alcuni di noi dovrebbero avere un vocabolario migliore, quindi di solito chiedo a un collega se non riesco a pensare a un buon nome inglese :)

Alcuni membri del nostro staff non sono norvegesi e quindi scrivere in inglese li avvantaggia. Essere in grado di assumere programmatori dalla maggior parte dell'Europa è positivo per l'economia, quindi anche la mia azienda ne beneficia.

BTW: Ricordo di aver letto la fonte di Hermes una volta (implementazione ebXML b2b) e avrei avuto delle difficoltà se avessero scritto e commentato in mandarino.

— Sylwester
fonte

5

Ho quasi modificato il "college" in quello che presumo sia "collega" ma non ero sicuro che fosse intenzionale.

— Jacob Schoen,

Ovviamente intendevo collega :)

— Sylwester il

Of course some words or concepts might not have a English counterpart- Sono sempre curioso quando si presenta in programmazione, quasi come se potessi conoscere un modello di progettazione che gli oratori solo inglesi non avrebbero escogitato. Hai un esempio veloce?

— Izkata,

5

@Izkata: la domanda riguardava le classi aziendali . Sono più spesso legati a norme e regolamenti specifici del Paese. Ad esempio, se la legge ti obbliga a tracciare la posizione di tutti i camion con sostanze chimiche pericolose, potresti benissimo nominare quella classe dopo quella legge.

— MSalters,

9

Credo che, poiché l'inglese è la lingua franca del dominio IT, limitare il codice sorgente a un'altra lingua crea ostacoli artificiali al suo sviluppo. Innanzitutto si limita il pool di persone che possono contribuire a quelle che parlano una lingua specifica. Lo stesso motivo che hai chiesto nello scambio di stack e non in un sito locale.

Inoltre non sai da dove verranno i contributi e dove andranno. Che cosa succede se utilizzi un campione da un sito, lo tradurrai? Cosa succede se il prodotto si espande per essere utilizzato da clienti in un altro paese? Hai bisogno di assumere un appaltatore / esternalizzare un po '? Perché limitarsi a un pool e non ottenere il massimo da tutto il mondo?

Si può presumere che sia OK per alcune strutture specifiche del dominio che non si associano facilmente ad altre lingue o se viene mantenuta una base di codice esistente.

— Dimitrios Mistriotis
fonte

9

Il mio ultimo obiettivo del progetto era quello di modellare il dominio commerciale di collaterali e mutui. Tutti gli sviluppatori e la società per cui abbiamo lavorato provengono dalla Polonia. Abbiamo creato il software seguendo i principi del Domain Driven Design. Abbiamo usato nomi polacchi per tutte le entità commerciali e penso che sia stata un'ottima scelta. Penso che siamo riusciti a evitare problemi di comunicazione grazie a questo approccio. Il dominio commerciale consisteva in molti termini che non conoscevo nemmeno in polacco, per non parlare delle traduzioni in inglese. Abbiamo usato solo lettere latine e tutte le classi tecniche sono state nominate in inglese.

— empi
fonte

4

Questo è un buon punto: se tutta la conoscenza del dominio è nella lingua locale e non esistono nomi inglesi concordati per i concetti del dominio, usare la lingua locale può essere una buona idea.

— Joachim Sauer,

7

È generalmente più semplice leggere il codice sorgente scritto in una sola lingua. Questo per la maggior parte dei linguaggi di programmazione implica che dovresti scriverlo in inglese.

Detto questo, c'è un grosso problema con i concetti di dominio che non si traducono facilmente in inglese. Un esempio tipico è un identificatore univoco che la società fornisce all'individuo: negli Stati Uniti il concetto più vicino è il numero di previdenza sociale, ma non è una mappatura accurata. Nomi e numeri di telefono di solito mappano abbastanza bene.

Credo che di solito sia necessario mantenere i termini del dominio ogni volta che una mappatura accurata non è prontamente disponibile in inglese, ma solo quelli - mantieni il resto in inglese. Si tradurrà in identificatori insoliti come KommuneImpl, ma dovrebbe avere senso immediato per coloro che conoscono il dominio.

2

Progetti di tipo comunità open-source / internazionali

La lingua comune dei progetti di comunità internazionali e open source è l'inglese. Caso in questione, la lingua dei siti Stack Exchange è l'inglese. Per la massima accessibilità, l'inglese dovrebbe essere usato per tutti i nomi di codice e oggetto.

Progetti commerciali

La maggior parte delle aziende di software internazionali richiedono che il codice sia scritto in inglese. È il massimo comune denominatore, quindi ha senso usare l'inglese come mezzo per creare coerenza.

Molte aziende di software regionali scrivono nella loro lingua madre. Non tutti seguono questo approccio, ma ha senso dal loro punto di vista: usano il linguaggio comune per tutti i loro sviluppatori.

Denominazione di oggetti business

Il linguaggio di codifica del team dovrebbe essere usato per nominare gli oggetti.
La priorità è che gli sviluppatori possano comunicare tra loro riguardo agli oggetti e ai requisiti del progetto. Se il team scrive in francese, gli oggetti business devono essere nominati in francese. Se codificano in inglese, allora denominano gli oggetti in inglese.

La tua domanda aggiunge una ruga perché il cliente parla una lingua madre diversa dalla lingua di programmazione del tuo team. Dovresti comunque usare il linguaggio di programmazione del tuo team per nominare gli oggetti.
Quando gli analisti o gli sviluppatori aziendali devono comunicare con il cliente in merito agli oggetti business specifici, può essere richiesta una traduzione del nome oggetto dalla lingua di codifica alla lingua del client secondo necessità. Dalla mia esperienza, è piuttosto raro che abbia parlato di oggetti di codice specifici con il client, quindi la traduzione nella lingua del client non è stata davvero necessaria.

L'unica eccezione alla regola di denominazione è quando un oggetto non ha altri termini sufficientemente concisi per catturare l'intento dell'oggetto. IMO, questo è davvero raro, ma può accadere. In realtà, però, è la stessa cosa che fanno le lingue parlate per esprimere concetti particolari. " Facciata " è in origine un termine francese, ma è stato adattato dall'inglese per esprimere il concetto ed è un modello di progettazione comune. " Schadenfreude " è un altro buon esempio di termine preso in prestito anche se non credo che abbia uno schema corrispondente.

1

Il tuo ultimo paragrafo contraddice totalmente il tuo primo, a quanto pare

— James,

@James - grazie! Ho rimosso quella sezione poiché al momento non ho il tempo di chiarire cosa intendevo dire. Doveva supportare, ma non importa.

1

In forte disaccordo. Poiché i concetti chiave praticamente di ogni lingua che incontrerai sono scritti in inglese, l'uso di una terminologia non inglese porta a codici sorgente meno leggibili. La mente deve costantemente saltare tra l'inglese e l'altra lingua. Il codice dovrebbe essere fluente e leggibile.

— Mike Adler,

@MikeAdler - non è chiaro se non sei d'accordo con ciò che suggerisco come regola generale (nome cose nella lingua del team) o caso di eccezione che dovrebbe essere molto raro.

Concesso. Chiarirò: non sono d'accordo sul fatto che qualsiasi oggetto debba mai essere nominato in una lingua diversa dall'inglese. La tua prima rubrica "Progetti di tipo open source / comunità internazionale" riflette molto bene il mio punto di vista. Dopo tutto, non sto comprando. La ragione, come detto, è la manutenibilità, che dovrebbe essere una preoccupazione prioritaria praticamente per ogni decisione di progettazione (incluso lo schema di denominazione) che prendi, secondo me.

— Mike Adler,