Fino a che punto dovremmo rinominare codice e dati quando cambiano le nomenclature degli utenti finali?

Molto tempo fa abbiamo aggiunto una funzione in cui i nostri utenti potevano "accettare" un'immagine dopo che era stata aggiunta a una coda del flusso di lavoro. A quanto pare, abbiamo usato il termine sbagliato e gli utenti hanno effettivamente "approvato" l'immagine.

Cambiare Accetta per approvare sulla nostra interfaccia è facile, basta sostituire una parola. Ma abbiamo programmato tutti i livelli con la parola "accetta", dal nome della classe CSS ai valori del database.

• La classe CSS che trasforma il pulsante in verde: ".accepted";
• Il metodo modello che verifica e associa l'attributo class sul nodo DOM: "isAccepted";
• Attributo di stato JavaScript: matrice con "non revisionato", "accettato" e "pubblicato";
• Colonna dello stato di Mysql: ENUM con "non revisionato", "accettato" e "pubblicato";
• Nomi dei test;

È banale (specialmente quando si hanno i test) sostituire la maggior parte delle occorrenze di accetta di approvare. Un po 'più difficile è migrare i dati, specialmente perché devono essere sincronizzati con la distribuzione.

Questo caso specifico è semplice, ma ho affrontato casi simili, ma più complessi, durante la mia carriera. Quando un file viene anche rinominato e la distribuzione avviene su dozzine di server, o quando sono coinvolti cache del proxy, memcached e mysql.

Lasciare "accettato" su ogni altro livello tranne l'interfaccia è una cattiva idea, dal momento che i nuovi programmatori che si uniscono al team potrebbero non apprendere i motivi storici che hanno portato a questa decisione, e mentre accetta -> approvare sono parole vicine in termini di significato, se esso è stato ribattezzato "in coda per il prossimo meeting manageriale di stato", sicuramente non avrebbe alcun senso. E sembra che se compromettiamo qua e là, in alcune iterazioni i concetti dell'interfaccia utente non avranno alcun orientamento con gli interni del sistema, e certamente non voglio lavorare su un sistema in cui metà dell'output non ha connessioni con le sue interiora.

Quindi, rinomini sempre tutto quando necessario? Se questo ti è successo e hai deciso che il compromesso non valeva la pena, è tornato a morderti? I commenti sul codice o la documentazione per gli sviluppatori sono sufficienti per evitare questo problema?

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

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

Potrebbe anche creare confusione in futuro e rendere più difficile per i nuovi sviluppatori comprendere la base di codice / dominio.

Dal contenuto della domanda e dai tag suppongo che tu stia usando un linguaggio onnipresente.

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

Quello che ho fatto di solito (e visto fatto) è:

• Refactoring iniziale 1 colpo: rifattorizza tutti i livelli dell'applicazione per adottare la lingua aggiornata; o
• registrazione del debito tecnico: è possibile modificare immediatamente il codice rivolto all'utente, quindi registrare le attività di debito tecnico per allineare il resto dei livelli dell'applicazione con la lingua aggiornata. Ciò si traduce in genere in una manciata di compiti noiosi (ma gestibili). (Perfetto per le 17:00!)

Penso che la cosa chiave 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 compiti così banali che non aggiungono alcuna funzionalità visibile. Questo è quando l' analogia del debito è 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 vantaggi offerti da DDD e UL. In termini di manager, aggiunge costi al progetto. Il codice diventa più difficile (costoso) da gestire e più confuso per i nuovi sviluppatori (costoso).

Potresti voler 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, l'utilizzo di l10n può consentire di modificare rapidamente ciò che viene visualizzato nell'interfaccia utente senza dover cambiare il termine utilizzato nel codice.

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

Se lo descrivi in ​​modo appropriato, il monitoraggio delle modifiche alla nomenclatura degli utenti finali in ogni parte della fonte è piuttosto un investimento. Ne vale comunque la pena, soprattutto per un prodotto di lunga durata sviluppato da un'infrastruttura completa (con hotline, tester, ecc.)

Tracciare la nomenclatura dell'utente finale nella fonte è un investimento perché ci sono così tanti tipi di componenti in cui appare e non c'è nessuna bacchetta magica che lavora simultaneamente su tutti questi componenti. Forse sviluppare una bacchetta così magica, componente dopo componente, è un investimento interessante che puoi diluire nel corso della vita del progetto.

Ho lavorato su una base di codice di 30 anni in cui la deriva tra la nomenclatura degli utenti finali e la nomenclatura interna è cresciuta particolarmente. Ecco alcuni svantaggi di questa situazione, che si aggiungono al sovraccarico del lavoro di tutti:

1. In assenza di una politica adeguata, il nuovo sviluppo tende a utilizzare l'attuale nomenclatura dell'utente finale. Pertanto, lo stesso concetto può avere due o più nomi in diversi componenti. Dal momento che i componenti interagiscono insieme, il risultato è che diversi nomi sono già presenti in modo similare in alcune parti locali del codice.

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

3. Quando il programmatore esegue il debug del codice, desidera impostare i punti di interruzione nelle funzioni pertinenti. È difficile trovare le funzioni appropriate se la nomenclatura dell'utente finale e la nomenclatura di origine non concordano. Potrebbe anche essere difficile o impossibile essere sicuri che un elenco delle funzioni pertinenti sia persino completo. (Vedi 1.)

4. In assenza di una politica adeguata, il mantenimento della fonte utilizzando una nomenclatura obsoleta di volta in volta metterà di nuovo questa nomenclatura obsoleta davanti agli utenti. Ciò produce cattive impressioni e causa spese generali.

Ho già rintracciato due giorni nel punto in cui alcuni dati vengono letti dal database e iniettati in alcuni componenti di questa base di codice. Perché se né io né nessuno della società in cui ho lavorato sono riuscito a trovare un nome che porta a questo posto, ho finalmente licenziato e ho deciso di trovare un'altra soluzione a quel problema.

Sebbene costare più di [1] due giorni di manutenzione senza produrre nulla (nessuna conoscenza, nessuna correzione, niente) è probabilmente il più grave possibile, le discrepanze tra nomenclatura utente e nomenclatura di origine aggiungono sovraccarico a molte attività di routine nel mantenimento di un software.

È importante notare che i costi generali aumentano con l'azienda produttrice del software, in una grande organizzazione, un rapporto sui problemi non arriverà sulla tua scrivania prima che sia stato preso in considerazione da diversi colleghi e la correzione potrebbe essere soggetta a test.

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

Non rinomino sempre codice e dati perché alcuni pacchetti sono condivisi tra i clienti. Fondamentalmente usano la stessa cosa ma la chiamano diversamente. Esempi, in un CMS, un client chiama il proprio cliente "Cliente" e un altro usa "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 lista controllo accessi, admin vs gestore, ecc. Può essere fonte di confusione per i nuovi arrivati ​​ma per componenti core come quelli, di solito ci sono sviluppatori core che si assicurano che quei componenti funzionino per tutti i client e facile da implementare anche da altri sviluppatori (ad es. creando etichette configurabili).

Potrebbe essere utile pensare che se si apporta questa modifica, si spera che non sarà necessario farlo di nuovo se lo stesso pezzo viene utilizzato da un altro cliente, fondamentalmente trasformandolo in un prodotto.