Come costruire un vocabolario condiviso dei termini del progetto su un team di sviluppatori?

Le revisioni del codice e la programmazione della coppia sono alcuni degli strumenti migliori per risolvere questi problemi man mano che si ottiene più informazioni sul codice e si può collaborare meglio per rendere più omogenea la denominazione. Dovrai discutere e avere un accordo su quali termini devono essere definiti o vincolati a un ambito specifico. Ti consiglio di iniziare in piccolo con circa 5 nomi che ti fanno sentire la più confusa e lavorare da lì. Sarebbe utile avere una qualche forma di documentazione a cui puoi puntare come fonte di verità che può essere indicata. Ricorda però che più termini cerchi di limitare, più è probabile che gli sviluppatori inizieranno a ignorare qualsiasi documentazione, o gli sviluppatori potrebbero ritenere che tutti i loro termini preferiti siano scontati.

Le soluzioni a questo problema sono politiche e hai bisogno di acquistare da tutti per evitare che uno sviluppatore si senta come se i loro contributi venissero scontati perché non ti piace come chiamano le cose. Gli sforzi per standardizzare cose come questa sono buone intenzioni, ma sono anche ottimi modi per far seguire in parte alcuni standard, rendendo il tuo codice come peggiore o peggio di prima.

Non sapevo cosa significasse l'Ubiquitous Language, e sembra essere quello che mancava per risolvere i miei problemi.

• Il vocabolario del modello di business è combinato con l'interfaccia utente e il vocabolario tecnico (ad esempio: la visualizzazione dell'interfaccia utente di testo del client di posta elettronica e un attributo di testo di un modello di email)

  Principio di responsabilità singola delle classi: avere una regola per non memorizzare alcun attributo di business in una classe View e non gestire View in una business class

• Gli sviluppatori traducono lo stesso concetto in modo diverso (ad esempio, la classe email nella vista dettagliata diventa Message in ListView - ma utilizza ancora gli stessi attributi)

  Linguaggio ubiquitario con una tabella di traduzione condivisa dei termini del dominio se il dominio non è in inglese. Parla con esperti di qualsiasi termine mancante per sapere come lo chiamerebbero

• Traduzioni approssimative e non condivise del modello tra gli sviluppatori - a volte a causa della mancanza di un vocabolario inglese che porta a termini usati troppo frequentemente (ad esempio: elemento, testo, etichetta, pulsante, gestore, gestore ...). Questi termini suonano bene, ma è difficile ottenere una definizione condivisa precisa di essi senza parlarne tra i membri del team.

  Ancora una tabella di conversione e una precisa definizione del team e i criteri di cosa sono Handler, Manager, Etichetta e altri termini tecnici ...)

• Fraintendimento dei concetti di business - che porta a mescolare concetti di business in una classe unica e a rompere il Principio di Responsabilità Unica.

  Parlate con esperti, chiedete all'OP di essere specifici sui termini usati nelle storie e nel dubbio chiedete una definizione chiara. Alla fine scrivi definizioni