Abbiamo un prodotto di lunga durata da circa 8 anni. Nel tempo, i nomi di concetti ed entità cambiano. Dovremmo impegnarci per rinominare tutte le tabelle e le colonne della base di codice e del database affinché corrispondano a questi nuovi nomi?
È stato pubblicato uno studio su questa o su alcune migliori pratiche?
Grazie
Risposte:
La discrepanza tra nomi interni ed esterni ha sicuramente un odore. Come sottolinea Rinzwind, gli omofoni e i sinonimi hanno l'odore peggiore.
La vera domanda a cui devi rispondere è: qual è il compromesso costi / benefici nel fare la modifica?
Il costo per non cambiare è una curva di apprendimento più ripida per i nuovi membri del team e una maggiore probabilità di futuri bug. Il costo del cambiamento è il tempo ovvio, una nuova curva di apprendimento per gli esperti del progetto e la possibilità di nuovi bug.
Se ti aspetti di avere un numero relativamente elevato di nuovi membri del team, è più probabile che abbia senso apportare la modifica. Se non ti aspetti un turnover, la squadra attuale non tende a confondersi e la squadra è soddisfatta dello status quo, quindi non ha molto senso rinominare le cose.
Se il codice dovrebbe durare a lungo e ci saranno nuovi sviluppatori che ci lavorano, farei le modifiche.
Può essere molto confuso e richiedere tempo per un nuovo sviluppatore entrare in un progetto e scoprire che i nomi delle entità sono fuorvianti.
C'è anche l'argomento valido di ... Se non è rotto, non aggiustarlo.
Per quanto riguarda la tua seconda domanda, non sono a conoscenza di studi pubblicati o migliori pratiche. Per quanto riguarda la prima domanda, posso offrire alcune osservazioni dall'esperienza personale con un prodotto di lunga durata simile in cui i nomi "interno" ed "esterno" sono talvolta diversi.
I nomi che vorrei davvero aggiustare sono gli "omofoni", in cui un nome viene utilizzato sia internamente che esternamente per cose diverse . Questo può essere davvero confuso, in particolare se le due cose non sono completamente diverse (tale contesto aiuta a chiarire le ambiguità). Un esempio (astratto) di ciò nella mia esperienza personale è dove internamente hai qualcosa come un Fooche è una raccolta di multipli FooEntity; esternamente, solo quest'ultimo è visibile ed è chiamato "Foo". Mi ci è voluto un po 'per capire che quando il manuale del cliente parlava di più "Foo", in realtà significava multiplo FooEntity(in un singolo Foo), se per te ha ancora senso.
In secondo luogo, vorrei correggere eventuali "sinonimi" in cui un nome esterno è stato utilizzato internamente. Come nei nomi di variabili, parti di nomi di metodi / funzioni e così via. Ciò accade spesso quando gli sviluppatori implementano qualcosa direttamente dalla descrizione dei requisiti del cliente e dimenticano di "tradurre" i nomi. Una volta che ciò accade, anche il nome "sbagliato" tende a diffondersi, perché altri sviluppatori copiano / incollano parte di quel codice da utilizzare come modello per il nuovo codice, ad esempio. Questi sinonimi non sono così confusi, ma possono essere fastidiosi perché se stai cercando il codice per qualsiasi riferimento a Barte potrebbe essere necessario tenere presente che alcune parti potrebbero riferirsi ad esso comeQux, quindi devi cercare due volte. (Questo potrebbe essere peggio nei linguaggi tipicamente dinamici rispetto a quelli statici, dato che devi cercare parti del nome di variabili / funzioni / ... piuttosto che sul nome del loro tipo.) Come nel caso contrario di "sinonimi ", Dove un nome interno è stato utilizzato esternamente: ciò tende a non accadere così spesso, poiché i dipendenti dell'assistenza clienti e così via sono generalmente meno consapevoli dei nomi interni, anche se presumo che sia confuso per i clienti quando accade.
Se riesci ad evitare o correggere almeno le due situazioni precedenti, non sono sicuro che dovresti arrivare al punto di rendere tutti i nomi interni uguali a quelli esterni. C'è probabilmente una buona ragione per cui i nomi interni non sono stati cambiati anche quando il nome esterno è stato reso diverso da quello interno in primo luogo. Nella mia esperienza personale, quella buona ragione è la necessità di supportare versioni precedenti del prodotto; potrebbe essere difficile unire una correzione di bug da una versione precedente alla pulizia dei nomi alla versione più recente se è necessario modificare un sacco di codice.
È un problema abbastanza comune. Un certo numero di progetti su cui ho lavorato usano nomi in codice anziché nomi di prodotti (che a quel punto potrebbero non essere stati decisi) e usano una terminologia selvaggiamente diversa nel codice rispetto a ciò che viene mostrato all'utente. Probabilmente lascerei le cose così come sono, a meno che tu non stia subendo una riproposizione massiccia del codice o se c'è qualcosa di specifico che causa problemi. Inutile rovesciare il carrello delle mele. Inoltre, chi può dire tra 5 anni non ci saranno più cambiamenti? E poi dovresti ripetere la ridenominazione. E non dimenticare che ciò influisce anche sulla documentazione del codice separata che potresti avere (API pubblicate), che potrebbe essere un problema particolarmente costoso se stampato (copia cartacea).
Trovo che spesso le entità "di marketing" non corrispondano esattamente alle entità interne. In tali casi, ha più senso introdurre un'entità a un diverso livello di astrazione, il che rende le differenze terminologiche un punto controverso.
Ad esempio, abbiamo un modello che rappresenta una gerarchia. A ciascun livello della gerarchia è associato un termine in base al modo in cui la gerarchia viene utilizzata per modellare le relazioni del mondo reale, ma internamente non esiste una differenza di comportamento da un livello della gerarchia a quello successivo. La terminologia è essenzialmente solo un nome per quel livello nella gerarchia, quindi per un particolare nodo nella struttura il nome descrive semplicemente quale sia il nodo; non prescrive alcun comportamento particolare.
Inoltre, l'albero è multi-root, quindi ci sono diversi nodi senza un genitore. Anche se concettualmente esiste una radice (rappresenterebbe essenzialmente l'universo) e includerla nel modello molte operazioni sarebbero molto più semplici, non esiste un "termine di marketing" per esso.
Naturalmente, componenti diversi nel nostro sistema usano una terminologia diversa. Sono stati sviluppati in tempi diversi da team diversi e non abbiamo il controllo su tutti. In realtà, ad un certo punto, qualcuno ha aggiunto o rimosso un livello in un componente, e quindi gli altri livelli sono spostati l'uno rispetto all'altro. Gli stessi tre livelli sono rappresentati da A, B e C in un componente, ma come B, C e D in un altro.
Fare un passo avanti nell'astrazione e modellare semplicemente tutto come un "nodo" o qualcosa di ugualmente generico rende questo tipo di modelli molto più facile da ragionare. Ogni nodo sa qual è il suo "termine di marketing" e il tipo che rappresenta un particolare termine di marketing può sapere cosa significa quel termine in ogni contesto.