Come faccio a gestire le variabili globali nel codice legacy esistente (o, cosa c'è di meglio, inferno globale o modello infernale)?

Un modo per spostarsi lentamente e in modo relativamente sicuro da globali a non globali potrebbe essere raggruppare globalmente in classi semi-ragionevoli nel miglior modo possibile. Dichiarare un'istanza globale della nuova classe, con membri che corrispondono alle globali che si stanno sostituendo. Rimuovi i globali. Guadare un numero potenzialmente elevato di errori del compilatore, cambiando ogni riferimento al globale con un riferimento al membro corrispondente dell'istanza globale.

Ora puoi passare gradualmente dall'avere le tue classi a conoscenza dell'istanza globale della tua nuova classe direttamente, e invece lanciare il barattolo verso il basso facendo passare l'istanza globale. Con il passare del tempo puoi sperare di dare un calcio alla lattina fino alla fine della strada, rimuovendo tutte le conoscenze dirette dell'istanza globale da ogni classe e, infine, eliminando l'istanza globale, dopo averla lentamente sostituita da un registro o dipendenza (a seconda di cosa hai fatto ogni volta che hai rimosso la conoscenza diretta dell'istanza globale da una delle tue classi).

Nota che ogni volta che una delle tue classi perde conoscenza diretta di come trovare l'istanza globale diventa più modificabile e verificabile, anche se l'istanza globale esiste ancora là fuori nella tua base di codice. In questo modo si ottengono dei vantaggi senza dover fare tutto il lavoro in anticipo, il che potrebbe richiedere troppo tempo con una base di codice di grandi dimensioni se il / i globale / i sono ampiamente referenziati.

Ovviamente, devi finire di fare tutto nel primo paragrafo. Con una grande base di codice tu e il tuo compilatore potrete trascorrere molto tempo insieme.

Quanto vai lontano dipende in gran parte dalla natura dei Globali. Se sono letti principalmente e raramente modificati (solo da poche posizioni facili da trovare), esiterei a fare cambiamenti radicali e fornirò un quadro sulle modifiche, basandomi sulla documentazione, sulla disciplina dei programmatori e sulla revisione del codice per garantire che il framework venga utilizzato.

Se tuttavia le variabili globali vengono cambiate da più posizioni o sempre (o entrambe), è necessario diventare più aggressivi con il refactoring.

Singletons - IMHO è un nome di fantasia per un globale per aggirare il dogma dei "Globali sono la via di tutti i mali" e per le lingue come Java che non ha alcun concetto di globale. Non saranno di grande aiuto in questo caso, a meno che il modello di utilizzo tenda naturalmente verso un Singleton (dalla lettura tra le righe dubito che questo sia il caso).

Registro - Opzione migliore, ma meno che ideale, a meno che gli articoli debbano essere veramente globali e lontani dall'ideale se vengono scritti regolarmente.

Dai un'occhiata attenta a questi aspetti globali e in primo luogo cerca di capire se dovrebbero essere globali. Se non c'è una ragione chiara, qualsiasi tentativo di risolverlo si sta occupando del sintomo, non della causa: sarà solo un bel po 'globale. Se decidi che risolverlo (come in, renderlo non globale) non è un'opzione, ragioni valide sono "non vale la pena" e "potrebbe infrangere altri codici in modi imprevisti" ecc., Quindi mettere un cerotto su di esso potrebbe essere una buona idea

5K SLOC non è un progetto di grandi dimensioni: prova a gestire 5 milioni di SLOC in questo stato. Con solo 5K SLOC, un importante refactoring non è un grosso sforzo se si dispone di un valido supporto per gli strumenti.

what's better, live with existing global variables or aggressively tune them with patterns like Singleton or Registry? Do you have any suggestions to these schemes, or have a better scheme?

Uno schema migliore sarebbe un'iniezione di dipendenza senza globali (o statici) di qualsiasi tipo.

Codice vecchio:

int DEFAULT_QUUX = 5;

int main() {
    Blip b;
    b.do_stuff(); // makes DEFAULT_QUUX = 6
    Qlip q;
    q.do_things(); // reads DEFAULT_QUUX
}

Nuovo codice:

int main() {
    int quux = 5; // no longer global
    Blip b{quux};
    quux = b.do_stuff(); // returns 6
    Qlip q;
    q.do_things(quux); // quux is dependency injected.
}

Se l'ipotetico Blip e Qlip usano o comunicano con altri oggetti nella loro implementazione, e quegli oggetti hanno bisogno di "quux" o di altri globali, questi dovrebbero essere iniettati nella catena di chiamate dall'alto.

Un problema serio con le variabili globali può essere il fatto che la variabile globale viene riutilizzata per controllare "sottosistemi" diversi a seconda del contesto corrente del programma. Quindi, cosa puoi fare:

1. Aggiungi una classe di registro globale per le variabili globali.
2. Verifica se la resposabilità per la variabile globale è in realtà solo per un dominio testando il software (ad esempio in un debugger o in un unittest).
3. Verifica se ha senso dividere la resposibilità della variabile globale.

E dovresti provare a creare test automatici quando esegui il refactoring a livello di unità o di test di integrazione.

Kim

Contrassegna tutte le globali con l'attributo [Obsoleto] (o qualsiasi altra cosa se non usi c #)

Imposta il cablaggio dell'infrastruttura per Iniezione delle dipendenze, in questo modo:

using (var mainForm = factory.Get<MainForm>()) {
      Application.Run(mainForm);
}

Quindi vai sulla tua attività implementando funzionalità dal backlog. Man mano che modifichi il codice esistente, l'IDE indicherà i cattivi attori (vars obsoleti). Quando incrociano il tuo percorso, prova ad ottenerlo dal contenitore di iniezione delle dipendenze. Non è necessario sostituire tutte le istanze in un grande cambiamento radicale che è garantito avere una ricaduta indesiderata.

Mentre procederai, avrai sempre più fiducia nei casi d'uso per uno o due di questi malvagi. Contemporaneamente, costruisci skilz con il tuo contenitore DI di tua scelta.

Poi, un giorno, quando il tuo contenitore DI viene cablato attraverso la maggior parte della tua base di codice, prendi una classe piuttosto scadente e cancelli tutti i [obsoleti] varselli. Lo fai estinguendo un dispositivo di prova con il più semplice dei test, l'istanziazione attraverso il tuo contenitore DI.

    var factory = new NinjectFactory();
    var mainForm = factory.Get<MainForm>();
    Assert.That(mainForm, Is.Not.Null, "MainForm"); 

Quindi trova una var globale e passa attraverso la funzione di costruzione. Il test fallirà se non hai configurato DI per la classe del var globale. Ovviamente, quella classe avrà delle dipendenze che dovrai srotolare, ma prova a svolgere solo quanto necessario per eseguire test (e si spera che App).

BTW - Sono al collo in una situazione simile in questo momento. (Un progetto molto più grande, però, il modulo principale da solo era 3k di codice!) È abbastanza soddisfacente una volta capito.