Programmazione e Ubiquitous Language (DDD) in un dominio non inglese

So che ci sono già alcune domande che sono strettamente correlate a questo argomento, ma nessuna di esse prende come punto di partenza il linguaggio Ubiquitous , quindi penso che giustifichi questa domanda.

Per chi non lo sapesse: Ubiquitous Language è il concetto di definizione di una lingua (sia parlata che scritta) che viene ugualmente utilizzata da sviluppatori ed esperti di dominio per evitare incoerenze e incomunicazioni dovute a problemi di traduzione e incomprensioni. Vedrai la stessa terminologia mostrata nel codice, conversazioni tra qualsiasi membro del team, specifiche funzionali e quant'altro.

Quindi, quello che mi chiedevo è come gestire la lingua ubiquitaria in domini non inglesi.

Personalmente, preferisco fortemente scrivere completamente il codice di programmazione in inglese, compresi i commenti ma ovviamente escludendo costanti e risorse.

Tuttavia, in un dominio non inglese, sono costretto a prendere una decisione in merito a:

1. Scrivi il codice che riflette la lingua Ubiquitous nel linguaggio naturale del dominio.
2. Traduci la lingua Ubiquitous in inglese e smetti di comunicare nella lingua naturale del dominio.
3. Definire una tabella che definisce come la lingua Ubiquitous si traduce in inglese.

Ecco alcuni dei miei pensieri basati su queste opzioni:

1) Ho una forte avversione per il codice in lingua mista, ovvero la codifica utilizzando nomi di tipo / membro / variabile ecc. Che non sono inglese. La maggior parte dei linguaggi di programmazione 'respira' l'inglese in larga misura e la maggior parte della letteratura tecnica, i nomi dei modelli di progettazione ecc. Sono anche in inglese. Pertanto, nella maggior parte dei casi non c'è proprio modo di scrivere il codice interamente in una lingua non inglese, quindi si finisce comunque con lingue miste.

2) Questo costringerà gli esperti del dominio a iniziare a pensare e parlare nell'equivalente inglese dell'UL, qualcosa che probabilmente non arriverà naturalmente a loro e quindi ostacola in modo significativo la comunicazione.

3) In questo caso, gli sviluppatori comunicano con gli esperti di dominio nella loro lingua madre mentre gli sviluppatori comunicano tra loro in inglese e, soprattutto, scrivono codice usando la traduzione inglese dell'UL.

Sono sicuro di non voler scegliere la prima opzione e penso che l'opzione 3 sia molto meglio dell'opzione 2. Cosa ne pensi? Mi mancano altre opzioni?

AGGIORNARE

Oggi, circa un anno dopo, dopo aver affrontato questo problema quotidianamente, devo dire che l'opzione 3 ha funzionato abbastanza bene per me.

Non è stato nemmeno noioso come inizialmente temevo e tradurre in tempo reale mentre parlavo con il cliente non era un problema.

Ho anche riscontrato che i seguenti vantaggi sono veri, in base alla mia esperienza.

• La traduzione dell'UL ti fa prestare maggiore attenzione alla definizione dell'UL e persino del dominio stesso, specialmente quando non sai come tradurre un termine e devi iniziare a cercare dizionari ecc. Questo mi ha persino portato a riconsiderare le decisioni di modellizzazione del dominio alcune volte.
• Ti aiuta a rendere più profonda la tua conoscenza della lingua inglese.
• Ovviamente, il tuo codice è molto più piacevole da guardare invece di essere un'oscenità da capogiro.

Ho affrontato spesso questo problema e, a mio avviso, la risposta è: "non esiste una risposta valida per tutti gli scenari".

Ma tieni presente che Ubiquitous Language non è un obiettivo in sé. È uno strumento per rafforzare la comunicazione tra il team e gli esperti del dominio e per rafforzare la coerenza concettuale del modello implementato in codice, test e conversazione.

Se riesci a parlare UL senza ambiguità sei sulla strada giusta. Se tu e i tuoi colleghi traducete continuamente da codice a conversazione o da concetto a concetto, allora probabilmente siete fuori strada.

In pratica, non tutti i domini sono uguali, né esperti di dominio. Alcuni domini hanno comunque molta terminologia inglese (domini tecnologici, per esempio) e sembra ragionevole optare per una scelta completamente inglese. Tuttavia, alcune culture potrebbero influenzare questa scelta (mi viene in mente il francese) e la diffusione della terminologia inglese varia da paese a paese. In alcuni altri domini (legale, per nominarne uno) non c'è modo di tradurre alcuni termini. O la traduzione renderebbe assolutamente più difficile per il Domain Expert seguire la conversazione.

In generale, siamo più interessati a ciò che ha da dire l'esperto di domini. Quindi vogliamo rendere le cose facili per loro. Altrimenti potrebbero semplicemente prendere una classe UML e leggere i nostri diagrammi (era uno scherzo). Quindi l'unica vera raccomandazione qui è: "presta attenzione al comportamento di Domain Expert", se sono coinvolti nella conversazione e la conversazione procede senza intoppi, probabilmente sei sulla buona strada, mantieni quella lingua. Potrebbe causare un po 'di lavoro extra alla squadra, ma va bene. Come sviluppatori siamo in qualche modo addestrati ad apprendere parole con un significato specifico in un contesto.

Stranamente, questa domanda è sempre accompagnata dal presupposto che tutto il codice debba parlare una sola lingua. Anche questo potrebbe essere sfidato. Non sono un inglese nativo e la conoscenza di una lingua straniera non è piatta: il mio cervello va veloce quando parla di nome , cognome , auto e simili, perde alcuni dettagli quando parla di codice postale , rallenta quando parla di prestito e sicuramente chiede per una spiegazione rassicurante quando si parla di mutuo .

Quindi, ancora una volta, scegli la migliore combinazione che farà fluire la conversazione chiave e fornirà la massima quantità di informazioni e feedback dall'esperto del dominio.

Di solito considero certe parole tecniche neutre dal punto di vista linguistico anche se esiste una traduzione nell'altra lingua.

Ad esempio, quando parlo di programmazione in tedesco, uso ancora il vocabolario tecnico inglese come se fossero parole tedesche anche se esiste un equivalente tedesco.

Nel tuo caso farei il contrario. Importa determinate parole tecniche dalla tua lingua madre in inglese proprio come le parole straniere sono state importate per secoli. Falli comportare grammaticalmente come le parole inglesi. All'inizio sembra strano, ma ti ci abituerai.

Concordo con il commento inglese "respirare" della maggior parte dei linguaggi di programmazione , che diventa sempre un problema con gli sforzi di sviluppo multilingue

Normalmente avrei l'UL nel linguaggio del tuo team di programmazione

Ciò che abbiamo fatto in passato è inventare nuove parole che esprimano meglio gli argomenti del dominio. Con un progetto francese / inglese le parole inventate erano per lo più basate in inglese ma con un sapore francese (non troppo difficile poiché molte parole inglesi sono comunque francesi), ma questo potrebbe applicarsi a qualsiasi mix linguistico

per esempio

"quantità bois"

In inglese è "quantità di legno" o "quantità di legno", in francese è "quantità di bois", quindi è abbastanza vicino per entrambi gli oratori. Ciò dovrebbe ridurre la quantità di nuove parole che ciascun oratore deve imparare

Quanto è grande il tuo dominio UL? Questo diventa il problema. Se contiene meno di 100 frasi chiave, puoi usare un linguaggio di stile composto da ibrido, se più grande attaccherei il linguaggio predominante degli sviluppatori poiché di solito devono affrontarlo più intensamente

Pubblica un dizionario wiki / thesaurus affinché tutti possano fare riferimento anche come richiesto, quindi non ci sono scuse per la comprensione

Di recente ho lavorato a un progetto DDD in Svizzera, dove il dominio era quello delle tasse (in particolare IVA e un altro tipo di imposta ... che non è facilmente traducibile in inglese ...).

Hanno scelto la prima opzione: UL in tedesco, usata anche nel codice in tedesco.

Prima di lavorare a questo progetto, avevo esattamente la tua stessa avversione per il codice in lingua mista. Mi piace (ancora) avere tutto in inglese, anche se non sono un madrelingua inglese. Inoltre non sono un madrelingua tedesco. Così, quando ho iniziato a esplorare la base di codice, ero inorridito.

Dopo un anno di lavoro su quel progetto, devo ammettere che penso che sia stata la decisione giusta in questo caso (avremmo potuto usare anche il francese o l'italiano, le altre lingue ufficiali svizzere, ma la maggior parte degli attori del progetto erano nativi tedeschi Altoparlanti).

Molti dei termini specifici del dominio non erano realmente traducibili in inglese in modo significativo. Ho dovuto comunque imparare i termini tedeschi per comunicare con il resto della squadra. Sarebbe stato più difficile imparare anche le traduzioni in inglese, che sarebbero state inventate dal nulla comunque.

Quindi immagino che dipenda davvero dal dominio. Alcuni domini saranno davvero difficili da tradurre in inglese e non avrà molto senso.

Probabilmente dipende anche dalla lingua madre. Il tedesco è una lingua in cui è possibile comporre le parole all'incirca nello stesso modo e soprattutto nello stesso ordine dell'inglese. Ad esempio una dichiarazione fiscale sarebbe una Steuerdeklaration . Non sorprendentemente diverso.

Non so come farei un nome di classe equivalente in francese, ad esempio, se il termine naturale fosse "déclaration d'impôts", con l'ordine opposto e una preposizione aggiuntiva nel mezzo ... E questo è giusto un semplice esempio. Sarei davvero interessato se qualcuno avesse esperienza con quel tipo di denominazione in lingue latine (francese, spagnolo, italiano, portoghese ...)!

Un'altra sfida erano le forme plurali, che in tedesco a volte sono difficilmente distinguibili dal singolare (mentre in inglese ha quasi sempre una s alla fine).

I caratteri accentati erano OK, poiché in tedesco tutti hanno un equivalente non accentuato ( ü -> ue e così via). È un altro punto in cui i francesi sarebbero più problematici ...