Quando il rebranding delle funzionalità dovrebbe essere seguito dal ridenominazione del modello e del codice? [chiuso]

In base alla mia esperienza, è bene essere preparati a modificare i nomi nel codice in seguito, per molti motivi possibili, il rebranding delle funzionalità è solo uno dei tanti motivi per cui ciò potrebbe verificarsi. Pertanto è sempre consigliabile prendere alcune misure in anticipo per rendere i rinominazioni nel codice il più semplice possibile.

Gli strumenti di refactoring aiuteranno. Le lingue tipizzate staticamente con un compilatore che ti avvisa quando commetti un errore nella ridenominazione aiuteranno. La scrittura del codice DRY aiuterà (quindi non ci sono più posti nel codice da modificare del necessario). Le tute di verifica dell'integrazione aiuteranno a confermare che non si è verificato un errore accidentale, per tutti i casi in cui il compilatore non può intercettarlo. Avere dei tester e una buona procedura di QA ti aiuterà in tutti i casi che i tuoi test di integrazione automatica non prenderanno. L'uso di nomi unici e ricercabili nell'intero codice aiuterà. Sarà utile avere una strategia e / o strumenti per introdurre le modifiche nello schema del database in seguito. Sarà utile avere una strategia collaudata per essere "retrocompatibile" con qualsiasi tipo di dati persistenti. Un processo di compilazione e distribuzione completamente automatizzato ti aiuterà.

Alla fine, questo è un compromesso, e qui non esiste una regola "taglia unica". Devi considerare quanto sforzo un cambio di nome specifico causerà nel tuo caso (non dimenticare l'implementazione testing e forti> sforzi) e confrontalo con quanto ti aspetti di ottenere dal ridenominazione nel tuo caso. Se la maggior parte delle basi sopra descritte è in atto, lo sforzo per cambiare i nomi potrebbe essere abbastanza piccolo da giustificarlo.