Quando dovrebbe essere utilizzata la lingua parlata del programmatore durante lo sviluppo? [duplicare]

Questa è un'ottima domanda.

In generale, preferisco mantenere le cose in inglese, perché è più o meno lo standard di fatto per lo sviluppo del software.

Tuttavia, credo anche nella creazione di modelli di dominio che rappresentano l'attività effettiva e il modello di dominio dovrebbe essere descritto in termini che hanno senso per gli stakeholder aziendali. E se l'azienda non è nativamente inglese, la creazione di un modello di dominio inglese viola questo principio. E in realtà ciò che accade in realtà è che tu, gli sviluppatori, inventi traduzioni che potrebbero essere o non essere corrette.

E ci sono probabilmente termini nella tua attività che non si traducono in inglese.

Uno di questi esempi è il concetto di "Sygedagpenge" in Danimarca. È un sistema in cui le persone con un lavoro possono ottenere benefici pubblici se per un lungo periodo non sono in grado di svolgere quel lavoro a causa di una condizione medica. Questa parola non può essere tradotta in nessuna lingua perché il sistema è puramente danese. Altri paesi probabilmente hanno sistemi simili, ma non è lo stesso sistema.

Quindi non provare a tradurre termini di dominio specifici per paese *. Indipendentemente dal fatto che tu scriva o meno l'intero modello di dominio / codice aziendale nella lingua nativa dell'azienda o se traduci il maggior numero possibile di inglese, solo le parole intraducibili nella lingua nativa dell'azienda sono a tua discrezione ** .

Tuttavia, la creazione dell'intero modello di dominio nella lingua nativa dell'azienda ti aiuterà, gli sviluppatori, a parlare meglio la lingua del business con gli stakeholder aziendali.

Ma personalmente terrei tutti i codici non commerciali in inglese, ad es. infrastruttura e codice GUI.

* Dato che dici di lavorare con tasse, IVA, ecc. Immagino che tu abbia alcuni termini specifici per paese, poiché probabilmente stai trattando le regole dettate dalla legislazione del tuo paese.

** Il sistema su cui sto lavorando attualmente, la maggior parte del modello di dominio è in inglese, ma abbiamo alcuni concetti che non possono essere tradotti, quindi li abbiamo tenuti in danese. Penso che questo approccio funzioni abbastanza bene nel nostro caso. Ma ciò non significa che preferirei questo approccio per il prossimo progetto.

Preferisco l'inglese con alcune piccole eccezioni.

Perché l'inglese:

• Se comunichi con altri sviluppatori è più facile per loro capire il tuo codice. Ad esempio, copia & incollare il codice italiano su stackexchange.com richiede molto tempo se devi tradurlo prima di pubblicare.

• Molti termini tecnici sono in inglese. Quindi tradurre questi termini dall'inglese in nomi specifici per paese è più complesso che usare termini inglesi pronti per l'uso.

• Se disponi di un modello di dominio specifico per paese, chiedi ai madrelingua inglesi le parole inglesi corrispondenti per il tuo dominio. È molto probabile che qualcuno abbia usato questi termini prima o possano esistere anche traduzioni inglesi molto descrittive ed espressive. Inoltre puoi verificare le tue condizioni commerciali in inglese e il tuo modello di dominio, perché i parlanti nativi inglesi spesso richiedono informazioni di base che spesso non ti consideri.

• Se vuoi cercare oltre la base di codice (ricerca di file, ricerca di membri, ricerca e sostituzione ...) è più facile da realizzare, se hai una lingua coerente. Immagina di cercare classi che hanno a che fare con la tassazione: è più facile cercare i due nomi IVA e IVA piuttosto che scoprire il numero di scarti di corrispondenti nomi italiani, giapponesi o danesi.

• Se il tuo progetto cresce e devi coinvolgere sviluppatori esterni, risparmia loro il dolore per tradurre il tuo codice.

• Alcuni compilatori o strumenti non amano i caratteri speciali. Quindi è meglio usare il set minimo di lettere inglesi.

• Migliora il tuo inglese; -)

Quando non lo è:

• Se hai termini o nomi personali molto specifici per paese, è meglio usare il nome personale, perché è più probabile che i madrelingua inglesi non lo traducano, pensa ai nomi delle strade o ad alcuni giorni festivi per esempio.

• Commenti Scrivo sempre nella lingua parlata dal pubblico principale [1], perché l'intento del codice dovrebbe essere il codice stesso. L'intento dei commenti è che il pubblico principale possa capire più facilmente l'intento del codice. Quindi se il pubblico principale parla russo, scrivi il commento in russo. Inoltre, la codifica in inglese e la scrittura di commenti nativi offrono una comprensione migliore e coerente del codice per i principali membri del progetto.

La mia regola decisionale:

per codice

Immagina di scrivere un libro, che scrivi per i consumatori di massa: se vuoi usare la parola nativa, usa anche la parola nativa nel tuo codice. Se la traducessi in termini espressivi in inglese, in modo che i tuoi lettori inglesi possano percepirne il significato, utilizza anche la traduzione inglese in modo coerente nella tua base di codice.

per i commenti

Scrivi commenti per il pubblico [1] come un recensore, una recensione nella lingua che il pubblico può percepire.

[1] Il pubblico non è un utente! Con il pubblico si intendono sviluppatori, revisori, manutentori e persone che devono gestire il codice!

Dipende dalla compagnia per cui lavori. Molte aziende chiederanno il codice sorgente solo in inglese, dal momento che ha più valore in questo modo (è possibile esternalizzare le funzionalità ad altri paesi con costi di supporto inferiori). Alcuni accettano la lingua locale per motivi specifici:

• nel livello aziendale, potresti trovare difficile tradurre termini specifici dell'attività. L'uso dell'inglese può causare qualche problema durante la modellazione del livello del dominio perché ogni sviluppatore deve creare il proprio vocabolario, a meno che uno standard non sia definito e utilizzato per il team
• la società non ha in programma di esternalizzare il suo lavoro di sviluppo

La mia regola empirica è descrivere ciò che il metodo fa a un anatra di gomma in inglese. Se devo usare una parola ebraica perché non esiste un equivalente inglese, il nome del metodo è in ebraico traslitterato. Se posso descrivere il metodo in inglese, il nome del metodo è inglese. Cerca di mantenere l'inglese come predefinito e italiano come eccezione rara.

Basta non fare nomi di metodi metà italiano, metà inglese. Questo confonde tutti, incluso te stesso quando vai a mantenerlo tra sei mesi!

In precedenza ho svolto uno stage di QA di 2 mesi presso una società di software nella filiale USA, ma l'HQ era in Giappone.

Tutte le funzioni e le variabili sono state scritte in inglese (anche se questo è più facile per i giapponesi poiché insegnano l'inglese come seconda lingua), ma tutti i commenti e la documentazione erano in giapponese. Quando abbiamo iniziato a costruire alcuni moduli, aggiungerei commenti in inglese. Sembrerebbe qualcosa di simile:

/*
日本語 comment
--------
English comment
*/
void doSomething() { }

Se lavori in un ambiente in cui tutti parlano una lingua, sentiti libero di usare quella lingua . Se lavori in un ambiente in cui sono utilizzate due o più lingue, è meglio usare la lingua più accettata universalmente da tutte le parti, che di solito finisce con l'essere inglese, ma può essere diversa.

Direi usare l'inglese, ma è più complicato del solo dirlo. Non utilizzerei public Money calcolaIVA() per lo stesso motivo per cui non utilizzerei public Money calculateVAT() , sono troppo specifici per il dominio.

IVA e IVA sono termini specifici del dominio che si applicano solo a ciascun paese. Anche quando diversi paesi usano la stessa terminologia, spesso hanno regole leggermente diverse che non ha senso usare la terminologia specifica del dominio qui.

Invece, userei public Tax[] getAllTaxes() , e uso un pattern di strategia per scegliere, in runtime, tra ItalianTaxRules() , UnitedKingdomTaxRules() , USTaxRules() , some_country = SimplePercentageTaxRule(0.05) , ecc.

Ciascuna strategia può quindi utilizzare terminologie specifiche del dominio nella lingua di destinazione per nomi nei commenti e nomi di classi, perché la traduzione di nomi specifici del dominio introdurrebbe quasi sempre confusione e ambiguità anche per le persone che non parlano la lingua .

I metodi pubblici tra strategia e contesto dovrebbero sempre usare terminologie generiche in inglese. I metodi privati all'interno della strategia stessa possono utilizzare il linguaggio specifico del dominio, a seconda dei casi, ma avrei usato solo verbi inglesi con nomi localizzati private Money calculateIVA() {} anziché private Money calcolaIVA() {} .

PS: sostituire l'inglese sopra con "The Common Language". "The Common Language" è la lingua che ti aspetti TUTTI i manutentori del programma ora e in futuro parlerà. Nella maggior parte delle situazioni, l'unica scelta ragionevole è l'inglese, ma potrebbero esserci situazioni in cui ha senso che "The Common Language" sia un'altra lingua.

Personalmente userò sempre l'inglese.

• L'inglese è una lingua di riferimento di fatto per lo sviluppo (tra gli altri).
• Le liraries di terze parti o l'API del servizio Web sono scritte in inglese. Sento che mescolare il linguaggio in quel caso è un po 'brutto e confuso.
• L'inglese è parlato anche in tutto il mondo, quindi è generalmente scelto da persone che parlano una lingua diversa per comunicare. Questo punto è il più importante per me perché vivo in un paese con tre lingue ufficiali e molti stranieri che lavorano come sviluppatori. Di conseguenza è abbastanza comune che i membri dei team di sviluppo parlino lingue diverse. Inoltre ho spesso lavorato a progetti sviluppati o mantenuti all'estero.
• Se hai intenzione di creare librerie, servizi web ..., è ovvio che sono necessarie API e documentazioni in inglese se vuoi che vengano utilizzate in tutto il mondo ..

Come menzionato in altre risposte, ci sono alcune restrizioni, ovviamente, come i termini specifici che sono difficili da tradurre in inglese, ma rimane abbastanza eccezionale e non dovrebbe farti preferire un'altra lingua.

Direi che dovresti fare tutto ciò che funziona meglio per le persone che guarderanno il tuo codice. Lo scopo dei nomi dei metodi, dei nomi delle variabili e dei commenti è di rendere chiaro l'INTENTO del tuo programma.

Se puoi ragionevolmente aspettarti che le uniche persone che leggeranno il codice saranno di madrelingua italiana, perché diavolo ti fanno provare a mettere in discussione le traduzioni in inglese? Inoltre, se l'inglese è una seconda lingua per te, quindi provare a tradurre tutto rischia di portare a commenti e nomi meno chiari rispetto a quanto avresti fatto con la tua lingua nativa.

Se, d'altro canto, non si prevede che i madrelingua siano madrelingua, l'inglese è probabilmente una buona scelta come seconda lingua.

Faccio alcune programmazioni da solo (anche se sono principalmente un amministratore di sistema) e abbiamo un grande team di sviluppo software qui sul sito.

Abbiamo un chiaro consenso tra le persone qui:

In generale, il linguaggio di programmazione stesso ha le sue basi in inglese.
Pertanto, a nostro avviso, l'utilizzo di nomi non inglesi per metodi, funzioni, variabili, ecc. È da evitare per impedire all'autore E al lettore di dover passare da una lingua all'altra.
Giocare mentalmente 2 lingue in generale non va bene per la comprensione generale e anche noioso.
L'ulteriore vantaggio è che ottenere un altro programmatore che lavora sul codice è più semplice poiché si può presumere che qualsiasi programmatore abbia una conoscenza pratica dell'inglese. (Nota: le conoscenze di lavoro non equivalgono a "buono", ma di solito è abbastanza buono da cavarsela.)

Scrivere anche i commenti in un'altra lingua va evitato, esattamente per gli stessi motivi.

L'unica eccezione a questa è denominare oggetti, funzioni, variabili che hanno un significato molto specifico nel contesto del programma e la lingua del pubblico di destinazione.

L'esempio già citato di una tassa che esiste solo in Italia è un ottimo esempio per illustrarlo: non ha senso cercare di tradurre il nome italiano di tale tassa in un'altra lingua. Per sottolineare veramente questo è specifico per l'Italia il nome italiano risalta e si assicura, in un secondo momento, nessun programmatore lo confonderà con un'altra (più generale) tassa menzionata anche da qualche parte nel programma.

Come molte altre persone dicono, l'inglese è piuttosto standard. Potresti dover pensare a quale potrebbe essere la durata del tuo codice.

Qualche tempo fa ho lavorato nell'ufficio di sviluppo indiano di un'azienda multinazionale europea e i miei membri del team sono stati intervallati da alcuni sviluppatori di un altro team in un progetto non correlato, ma tutti noi abbiamo avuto modo di ascoltare le discussioni e i problemi di ogni altro . Il problema che l'altra squadra ha avuto è che questa gigantesca compagnia ha comprato una piccola start-up finlandese (o ha appena comprato il suo software, non sono chiaro) che ha scritto tutto il suo codice in finlandese.

Nessuno dei membri del team indiano ha parlato di finlandese. Trascorsero mesi e mesi cercando di tradurre il codice, o almeno, le parti non specifiche del codice del codice. Un sacco di ricerca e sostituzione, ricompilazione, errori, correzione, errori, ricompilazione.

Tutto sommato, a causa di Finlandese vs Inglese, la società non ha ottenuto alcun utilizzo produttivo dal loro acquisto.

Direi mai.

È meglio per te e per il manutentore avere una lingua comune (inglese). non sai quando la tua lingua non sarà in grado di esprimere ciò che stai facendo, parlo 4 lingue diverse. Non ho padronanza dell'inglese, non è nemmeno la mia lingua migliore, ma qualsiasi commento o definizione si adatta meglio in inglese rispetto a qualsiasi altro.

E devo aggiungere che questo può aiutarti a migliorare la tua conoscenza dell'inglese tecnico, la tua capacità di comprendere forum globali che probabilmente non saranno in italiano.