Quanto dovremmo rinominare il codice e i dati quando cambiano le nomenclature degli utenti finali?

Per me, è decisamente meglio cambiare tutto ciò che riguarda l'oggetto in questione.

È una forma di degrado del codice e mentre 1 elemento non modificato potrebbe non essere un grosso problema, imposta il tono per il codice base.

Potrebbe anche portare a confusione in futuro e rendere più difficile per i nuovi sviluppatori capire il codice base / dominio.

Dai contenuti e tag delle domande presumo che tu stia utilizzando un linguaggio ubiquo.

Nella mia esperienza UL è eccezionale ma, come hai detto, può portare a ulteriori compiti di manutenzione man mano che il linguaggio evolve. Questo, di per sé, non è una brutta cosa. Certo, è scomodo, ma è anche previsto.

Quello che in genere ho fatto (e visto fatto) è:

• refactoring iniziale 1-shot: refactoring tutti i layer dell'applicazione per adottare la lingua aggiornata; o
• log debt tecnico: è possibile modificare subito il codice rivolto all'utente e quindi registrare le attività del debito tecnico per allineare il resto dei livelli dell'applicazione alla lingua aggiornata. Questo in genere comporta una manciata di compiti noiosi (ma gestibili). (Perfetto per le 17:00!)

Penso che la cosa fondamentale qui sia che ciò che stai descrivendo è debito tecnico e dovrebbe essere riconosciuto come tale.

Ho avuto manager che hanno sostenuto che non dovremmo perdere tempo in attività così banali che non aggiungono alcuna funzionalità visibile. Questo è quando l'analogia debito diventa davvero utile. Si riduce a questo:

Il team ha scelto di fare DDD con Ubiquitous Language. Allontanarsi da questo approccio lasciando il codice in uno stato incoerente aggiunge confusione e rimuove molti dei benefici forniti da DDD e UL. In termini di gestore, aggiunge un costo al progetto. Il codice diventa più difficile (costoso) da gestire e più confuso per i nuovi sviluppatori (costoso).

Potrebbe essere utile esaminare le opzioni di localizzazione (l10n). Anche se potrebbe non sembrare così drastico come passare dall'inglese allo spagnolo, hai a che fare con un termine diverso per lo stesso concetto. Se questo sembra accadere comunemente, quindi l'utilizzo di l10n può consentire di modificare rapidamente ciò che viene visualizzato nell'interfaccia utente senza dover cambiare il termine usato nel codice.

Con questo, basta usare i termini nel codice che sono quelli più ampiamente compresi. Scegli i nomi dal dominio come gli sviluppatori lo sanno e potrebbero aspettarselo.

Come la descrivi correttamente, monitorando la nomenclatura degli utenti finali i cambiamenti in ogni parte della fonte sono piuttosto un investimento. È comunque ne vale la pena, soprattutto per un prodotto long life sviluppato da un'infrastruttura completa (con hotline, tester, ecc.)

Tenere traccia della nomenclatura degli utenti finali nella fonte è un investimento perché ci sono così tanti tipi di componenti in cui appare e non c'è bacchetta magica che funziona simultaneamente su tutti questi componenti. Può essere sviluppare una bacchetta magica, componente dopo componente, è un investimento interessante che si può diluire nel corso della vita del progetto.

Ho lavorato su un codebase di 30 anni in cui la deriva tra l'utente finale la nomenclatura e la nomenclatura interna divennero particolarmente grandi. Qui sono alcuni inconvenienti di questa situazione, che tutti aggiungono al sovraccarico del lavoro di tutti:

1. In assenza di una politica adeguata, il nuovo sviluppo tende a utilizzare il attuale nomenclatura dell'utente finale. Quindi, lo stesso concetto potrebbe avere due o più nomi in diversi componenti. Poiché i componenti interagire insieme, questo si traduce in diversi nomi sinonimi esistenti in modo simulativo in alcune parti locali del codice.

2. Quando viene chiamata la hotline / help desk, scrivono una user story usando nomenclatura per utente finale. Lo sviluppatore incaricato di risolvere il il problema deve tradurre la nomenclatura dell'utente finale in modo che corrisponda al nomenclatura di origine. Ovviamente non è archiviato, e ovviamente lo è è un disastro. (Vedi 1.)

3. Quando il programmatore esegue il debug del codice, desidera impostare i breakpoint in funzioni rilevanti. È difficile trovare l'appropriato funziona se la nomenclatura dell'utente finale e la nomenclatura di origine non essere d'accordo. Potrebbe anche essere difficile o impossibile essere fiduciosi che un elenco delle funzioni rilevanti è addirittura completo. (Vedi 1.)

4. In assenza di una politica adeguata, mantenimento della fonte utilizzando un la nomenclatura obsoleta di volta in volta lo renderà obsoleto nomenclatura di nuovo davanti agli utenti. Questo produce poveri impressione e cause generali.

Ho già rintracciato per due giorni il luogo in cui si trovano alcuni dati leggere il database e iniettato in alcuni componenti di questo codebase. Perché se io o nessuno della compagnia in cui lavoravo potevo farlo figurare un nome che porta a questo posto che alla fine ho licenziato e ho deciso di farlo trova un'altra soluzione a questo problema.

Mentre costano più di [1] due giorni di manutenzione senza cedere qualsiasi cosa (nessuna conoscenza, nessuna correzione, niente) è probabilmente il peggiore possibile ottenere, discrepanze tra nomenclatura utente e nomemlatura di origine aggiungere un sovraccarico a molte attività di routine nella manutenzione di un software.

È importante notare che i costi generali aumentano con l'azienda producendo il software, in una grande organizzazione, lo farà una segnalazione del problema non arrivare sulla tua scrivania prima che sia stato considerato da diversi i colleghi e la correzione potrebbero essere soggetti a test.

[1] A causa del coinvolgimento di più di uno sviluppatore.

Non sempre rinominerò il codice e i dati perché alcuni pacchetti sono condivisi tra i clienti. Fondamentalmente usano la stessa cosa ma la chiamano in modo diverso. Esempi, in un CMS, un cliente chiama il cliente "Cliente" e un altro utilizza "Cliente". Quindi abbiamo sostituito il cliente con il cliente in superficie per un cliente, ma CMS sarà sempre un sistema di gestione dei clienti.

Un altro esempio è la gestione degli utenti con termini come permessi vs elenco controllo accessi, amministratore vs manager, ecc. Può essere fonte di confusione per i nuovi arrivati ma per componenti di base come quelli, di solito ci sono gli sviluppatori principali che si assicurano che quei componenti funzionino per tutti i client e anche facilmente implementabili da altri sviluppatori (ad esempio creando etichette configurabili).

Potrebbe essere utile pensare che se apporti questa modifica, spero che non dovrai farlo di nuovo se lo stesso pezzo viene utilizzato da un altro cliente, trasformandolo in un prodotto.