Sto richiedendo le migliori pratiche con questa domanda. Questo è solo un problema se la società cliente è strettamente nazionale ha una lingua madre diversa dall'inglese, credo.
Se il cliente ha molte espressioni prevalentemente specifiche del dominio (ad esempio, tedesco), mescolato con alcune denominazioni meno specifiche del dominio. La lingua dei nostri commenti di codice, classe / metodo / nomi di variabili è l'inglese. Traducete tutti i nomi specifici del dominio?
Lavoro in Germania e preferisco scegliere l'inglese.
A volte, ad es. cose specifiche del dominio come la creazione di un modulo per "DATEV" (tedesco fattura / software di fatturazione) io uso nomi tedeschi. Alcune parole tedesche non possono essere tradotte correttamente, ad es. "Referenzbuchungsnummer" (ReferenceBookingNum?) O "Sachkontenlaenge" (..?). Inoltre, penso che le cose specifiche del dominio finirebbero con la manutenzione horror. Forse ricorderesti che ReferenceBookingNum si riferirebbe a "Referenzbuchungsnummer", ma per quanto riguarda i tuoi colleghi di lavoro? Devono studiare la documentazione interna sulla denominazione, se la documentazione esiste. 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.
Essendo norvegese che lavora in una compagnia norvegese, chiamo i miei oggetti in inglese. Ovviamente alcune parole o concetti potrebbero non avere una controparte inglese e in tal caso si può sostenere che una parola nativa potrebbe essere usata al posto di una cattiva sostituzione 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 di ebXML b2b) e avrei avuto difficoltà se avessero scritto e commentato in mandarino.
Credo che dal momento che l'inglese è la lingua franca del dominio IT, limitare il codice sorgente a un'altra lingua crea ostacoli artificiali al suo sviluppo. Prima si limita il pool di persone che possono contribuire a quelle che parlano una lingua specifica. La stessa ragione per cui hai chiesto nello scambio di stack e non su un sito locale.
Inoltre non sai da dove verranno i contributi e dove andranno a finire. Cosa succede se usi un campione da un sito, lo tradurrai? Cosa succede se il prodotto si espande per essere utilizzato da clienti in un altro paese? Caso hai bisogno di assumere un appaltatore / esternalizzare un po '? Perché limitare 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 mappano facilmente ad altre lingue, o se viene mantenuto un code base esistente.
Il mio ultimo obiettivo del progetto era modellare il dominio aziendale di garanzie e ipoteche. Tutti gli sviluppatori e la società per cui abbiamo lavorato sono dalla Polonia. Abbiamo costruito il software seguendo i principi del Domain Driven Design. Abbiamo usato nomi polacchi per tutte le entità aziendali e penso che sia stata una scelta molto buona. Penso che siamo stati in grado di evitare problemi di comunicazione grazie a questo approccio. Il dominio aziendale 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 denominate in inglese.
In genere è più semplice leggere il codice sorgente scritto in una singola 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 sicurezza sociale, ma non è una mappatura accurata. Nomi e numeri telefonici di solito si associano 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 - mantenere il resto in inglese. Risulterà in identificatori insoliti come KommuneImpl ma dovrebbe avere un senso immediato per coloro che conoscono il dominio.
Il linguaggio comune dei progetti di comunità open source e internazionali è 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.
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.
Il linguaggio di codifica del team dovrebbe essere usato per nominare gli oggetti.
La priorità è che gli sviluppatori siano in grado di comunicare tra loro in merito agli oggetti e ai requisiti del progetto. Se il team scrive in francese, gli oggetti di business dovrebbero essere denominati in francese. Se codificano in inglese, quindi denominano gli oggetti in inglese.
La tua domanda aggiunge una piega perché il client parla una lingua nativa diversa dalla lingua di codifica del tuo team. Dovresti comunque utilizzare la lingua di codifica del tuo team per nominare gli oggetti.
Quando gli analisti aziendali o gli sviluppatori devono comunicare con il cliente in merito agli specifici oggetti di business, può essere necessaria una traduzione del nome dell'oggetto dal linguaggio di codifica alla lingua del cliente. Dalla mia esperienza, è piuttosto raro che io abbia parlato di oggetti di codice specifici con il cliente, quindi la traduzione nella lingua del client non è stata realmente necessaria.
L'unica eccezione alla regola di denominazione è quando un oggetto non ha altro termine sufficientemente conciso per catturare l'intento dell'oggetto. IMO, questo è davvero raro, ma può verificarsi. In realtà però, è la stessa cosa che i linguaggi parlati fanno per esprimere concetti particolari. " Facade " è 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 un termine preso in prestito anche se non penso che abbia uno schema corrispondente.
Leggi altre domande sui tag naming