Abbiamo avuto un prodotto di lunga vita da circa 8 anni. Nel corso del tempo, cambiano i nomi dei concetti e delle entità. Dovremmo inserire il lavoro per rinominare tutti i codici base e le tabelle e le colonne del database in modo che corrispondano a questi nuovi nomi?
È stato pubblicato uno studio su questo o su alcune best practice?
Grazie
La discrepanza tra i nomi interni ed esterni ha decisamente un odore. Come sottolinea Rinzwind, gli omofoni e i sinonimi hanno il peggio.
La vera domanda a cui devi rispondere è: qual è il compromesso tra costi e benefici nell'apportare la modifica?
Il costo di 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 i veterani del progetto e la possibilità di nuovi bug.
Se si prevede di avere un numero relativamente grande di nuovi membri del team, è più probabile che abbia senso apportare la modifica. Se non ti aspetti alcun turnover, la squadra attuale non tende a confondersi e il team è soddisfatto dello status quo, quindi non ha senso rinominare le cose.
Se si prevede che il codice durerà a lungo e ci saranno nuovi sviluppatori che lavoreranno su questo, vorrei apportare le modifiche.
Può essere molto complicato e dispendioso in termini di tempo per un nuovo sviluppatore di entrare in un progetto e trovare i nomi delle entità fuorvianti.
C'è anche l'argomento valido di ... Se non è rotto, non aggiustarlo.
Riguardo alla tua seconda domanda, non sono a conoscenza di alcuno studio o best practice pubblicati. Per quanto riguarda la prima domanda, posso offrire alcune osservazioni sull'esperienza personale con un prodotto simile di lunga vita in cui i nomi "interni" e "esterni" sono talvolta diversi.
I nomi che vorrei davvero risolvere sono gli "omofoni", in cui un nome è usato sia internamente che esternamente per le cose diverse . Questo può essere davvero fonte di confusione, in particolare se le due cose non sono completamente diverse (tale che il contesto aiuta a disambiguare). Un esempio (astratto) di ciò nella mia esperienza personale è dove internamente si ha qualcosa come un Foo che è una raccolta di più FooEntity ; esternamente, solo quest'ultimo è visibile e viene chiamato "Foo". Ci ho messo un po 'a capire che quando il manuale del cliente parlava di più "Foo" significava in realtà più FooEntity (in un singolo Foo ), se questo ha ancora senso per te.
In secondo luogo, vorrei correggere eventuali "sinonimi" in cui qualche 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. Quando ciò accade, anche il nome 'sbagliato' tende a diffondersi, perché altri sviluppatori capita di copiare / incollare 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 Bar potresti dover tenere a mente che alcune parti potrebbero riferirsi ad esso come Qux , quindi devi cercare due volte. (Questo potrebbe essere peggio nelle lingue dinamicamente tipizzate rispetto a quelle statiche, dato che devi cercare su parti del nome di variabili / funzioni / ... piuttosto che sul nome del loro tipo.) Per quanto riguarda il caso inverso di "sinonimi" ", Dove un nome interno è stato utilizzato esternamente: questo tende a non accadere più spesso, poiché i dipendenti del servizio clienti e così via sono solitamente meno consapevoli dei nomi interni, anche se presumo che sia confuso per i clienti quando accade.
Se riesci a evitare o correggere almeno le due situazioni precedenti, non sono sicuro se dovresti arrivare fino a rendere tutti i nomi interni uguali a quelli esterni. C'è probabilmente una buona ragione per cui i nomi interni non sono stati modificati anche quando il nome esterno è stato reso diverso da quello interno in primo luogo. Nella mia esperienza personale, questa buona ragione è la necessità di supportare versioni precedenti del prodotto; potrebbe diventare difficile unire una correzione di bug da una versione precedente alla pulizia dei nomi alla versione più recente se è necessario modificare molto codice.
È un problema abbastanza comune. Un certo numero di progetti su cui ho lavorato utilizza i nomi in codice anziché i nomi dei prodotti (che potrebbero non essere stati decisi in quel momento) e utilizzano una terminologia selvaggiamente differente nel codice rispetto a ciò che viene visualizzato all'utente. Probabilmente lascerei le cose così come sono, a meno che tu non stia subendo una radicale ri-proposizione del codice o se c'è qualcosa di specifico che causa problemi. Non serve a sconvolgere il carrello delle mele. Inoltre, chi dirà 5 anni da oggi non ci saranno più cambiamenti? E poi dovresti ricominciare a rinominare. E non dimenticare, ciò influisce anche su qualsiasi documentazione di codice separata che potresti avere (API pubblicate), che potrebbe essere un problema particolarmente costoso se stampato (copia cartacea).
Io dico di correggerlo in ogni caso in cui il codice è destinato a essere mantenuto per un certo periodo di tempo. Probabilmente salverà confusione e tempo in futuro.
Trovo spesso che le entità di "marketing" non corrispondano esattamente con le entità interne. In questi 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 ogni 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 nodo particolare nell'albero il nome descrive semplicemente cos'è 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 renderebbe molte operazioni molto più semplici, non ci sono "termini di marketing" per questo.
Naturalmente, diversi componenti del nostro sistema usano una terminologia diversa. Sono stati sviluppati in momenti diversi da squadre diverse, e non abbiamo il controllo su tutti loro. In realtà, a 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 semplicemente modellare tutto come un "nodo" o qualcosa di altrettanto generico rende molto più facile ragionare su questo tipo di modelli. 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.