Cattiva pratica: cambia caso per impostare l'ambiente

31

Negli ultimi tre anni in cui ho lavorato come sviluppatore, ho visto molti esempi in cui le persone usano un'istruzione switch per impostare il percorso (sia in back-end che front-end) per un URL. Di seguito è riportato un esempio di questo:

Esempio di back-end (C #):

public static string getHost(EnvironmentEnum environment){
    var path = String.Empty;
    switch (environment)
    {
        case EnvironmentEnum.dev:
            path = "http://localhost:55793/";
            break;
        case EnvironmentEnum.uat:
            path = "http://dev.yourpath.com/";
            break;
        case EnvironmentEnum.production:
            path = "http://yourpath.com/";
            break;
    }
    return path;
}

Esempio di front-end (JavaScript):

(function () {
    if (window.location.host.indexOf("localhost") !== -1) {
        window.serviceUrl = "http://localhost:57939/";
    }
    else if (window.location.host.indexOf("qa") !== -1) {
        window.serviceUrl = "http://dev.yourpath.com/";
    }
    else {
        window.serviceUrl = "http://yourpath.com/";
    }
})();

È stato discusso se sia una buona o cattiva pratica, e penso che sia una cattiva pratica, perché dobbiamo evitare questo tipo di codice e impostare una configurazione corretta. Ma sinceramente non conosco la risposta corretta e perché non è raccomandata e qual è il modo corretto di implementarlo.

qualcuno può spiegargli i pro ei contro della pratica di cui sopra?

    
posta gon250 06.07.2015 - 16:21
fonte

5 risposte

81

Il codice che funziona per te ed è facile da mantenere è per definizione "buono". Non dovresti mai cambiare le cose solo per obbedire all'idea di qualcuno di "buona pratica" se quella persona non può indicare quale sia il problema con il tuo codice.

In questo caso, il problema più ovvio è che le risorse sono codificate nella tua applicazione, anche se sono selezionate dinamicamente, sono ancora codificate. Ciò significa che non è possibile modificare queste risorse senza ricompilare / ridistribuire la propria applicazione. Con un file di configurazione esterno, dovresti solo cambiare quel file e riavviare / ricaricare la tua applicazione.

Se questo è un problema dipende da cosa lo fai. In un framework Javascript che viene comunque ridistribuito automaticamente ad ogni richiesta, non c'è alcun problema - il valore modificato verrà propagato a ogni utente al successivo utilizzo dell'applicazione. Con una distribuzione locale in un linguaggio compilato in una posizione inaccessibile, è davvero un grosso problema. La reinstallazione dell'applicazione potrebbe richiedere molto tempo, costare un sacco di soldi o essere eseguita di notte per preservare la disponibilità.

Il fatto che i valori codificati siano o meno un problema dipende dal fatto che la tua situazione sia più simile al primo esempio o più simile al secondo esempio.

    
risposta data 06.07.2015 - 16:32
fonte
14

Hai assolutamente ragione nel pensare che questa sia una cattiva pratica. L'ho visto nel codice di produzione e torna sempre a morderti.

Cosa succede quando vuoi aggiungere un altro ambiente? O cambia il tuo server di sviluppo? O è necessario eseguire il failover in un'altra posizione? Non puoi perché la tua configurazione è direttamente legata al codice.

La configurazione dovrebbe essere forzata dal codice e nell'ambiente stesso. È un principio di App Twelve-Factor ( link ), ma è una buona pratica per qualsiasi applicazione. Potresti scoprire che le variabili d'ambiente non sono appropriate per la tua situazione, nel qual caso suggerirei di archiviare quella configurazione in un database di file di configurazione a fianco (ma non archiviato con) codice.

    
risposta data 06.07.2015 - 16:32
fonte
5

Per uno, (come altri hanno già detto) questa è una cattiva idea perché stai legando i dettagli di implementazione nel tuo codice. Questo rende difficile cambiare le cose.

Come menzionato in questa risposta , se vuoi aggiungere un nuovo ambiente ora devi aggiornare il tuo codice ovunque , invece di aggiungere il tuo programma a un nuovo ambiente.

C'è un altro grave difetto nel fare questo nel tuo codice Javascript: stai esponendo gli interni della tua azienda a potenziali aggressori. Certo, potresti essere dietro un firewall, ma potresti comunque avere un dipendente scontento o qualcuno che fa entrare un virus.

Orsi di cattive notizie.

La cosa migliore da fare è impostare la configurazione dall'ambiente (come nella risposta precedentemente collegata, l'app Twelve-Factor ha ottimi consigli sull'argomento). Ci sono diversi modi per farlo a seconda della tua lingua. Uno dei più semplici (di solito) è impostare semplicemente le variabili di ambiente. Quindi devi solo cambiare le variabili a seconda di dove stai correndo, indipendentemente dal fatto che si tratti di una scatola di sviluppo locale, di un qa o di una produzione. Un'altra opzione è la memorizzazione dei valori in un file .ini o JSON. Un'altra alternativa potrebbe essere memorizzare i valori di configurazione come codice effettivo. A seconda della lingua o dell'ambiente in uso, potrebbe essere una buona idea o meno.

Ma l'obiettivo finale è quello di farti prendere una base di codice, rilasciarla su qualsiasi macchina che abbia l'architettura / connettività supportata, ed essere in grado di eseguirla senza modificare il codice in alcun modo.

    
risposta data 06.07.2015 - 21:54
fonte
1

Che cosa succede se voglio eseguire il back-end sul mio computer ma non sulla porta 55793, ad esempio se eseguivo più versioni contemporaneamente per confrontarle? Cosa succede se voglio eseguire il back-end dell'applicazione su una macchina, ma accedervi da un'altra? Cosa succede se voglio aggiungere un quarto ambiente? Come altri hanno sottolineato, è necessario ricompilare solo per modificare la configurazione di base.

L'approccio che hai descritto potrebbe aver funzionato in pratica per la tua squadra fino ad ora, ma è inutilmente restrittivo. Un sistema di configurazione che consente di impostare arbitrariamente parametri come questo percorso in un file di configurazione centrale è molto più flessibile di uno che fornisce solo opzioni fisse e che vantaggio guadagni con l'approccio switch statement? Nessuno!

    
risposta data 07.07.2015 - 01:22
fonte
0

È una CATTIVA PRATICA .

Un principio di base del design del software: Non codificare i valori di configurazione all'interno dei tuoi programmi. Questo è particolarmente vero per tutto ciò che ha una ragionevole possibilità di cambiare in futuro.

Il codice del programma che sviluppi deve essere lo stesso codice che va in qualsiasi ambiente come test del QA, UAT e produzione. Se qualcuno ha bisogno di cambiare la configurazione in seguito perché l'ambiente è cambiato, o hanno bisogno di usarlo in un nuovo ambiente, va bene. Ma non dovrebbero mai dover toccare il codice del programma per farlo. E non dovresti avere versioni differenti di codice per ogni ambiente. Se il tuo programma è cambiato da quando è stato testato, allora non hai testato quella versione. Chiedi a qualsiasi ingegnere del software, a qualsiasi professionista della garanzia della qualità del software, qualsiasi I.T. project management professional, any I.T. revisore dei conti.

Qualcuno potrebbe spostare i test su un altro server. Qualcuno potrebbe decidere anche di volere un ambiente di formazione per gli utenti o un ambiente per le dimostrazioni di vendita. Non dovrebbero andare in un programmatore per la configurazione amministrativa.

Il software dovrebbe essere abbastanza flessibile e robusto da gestire situazioni impreviste, entro limiti ragionevoli.

Inoltre, il software non dovrebbe essere scritto semplicemente, ma al momento sembra più semplice per te. Il costo dello sviluppo del software è ridotto rispetto al costo della manutenzione del software nel corso della sua durata. E diciamo un anno da adesso, potresti non essere la persona che lavora su quel codice. Dovresti pensare a cosa stai lasciando per il prossimo povero cretino che deve raccogliere tutto il disordine che potresti aver lasciato alle spalle, forse anni dopo che sei passato ai pascoli più verdi. Oppure potresti essere colui che riprende il codice anni dopo, non credendo a quello che hai fatto allora.

Codifica le cose correttamente, nel miglior modo possibile. È meno probabile che diventi un problema più tardi.

    
risposta data 08.07.2015 - 00:33
fonte