Cattiva pratica - cambia caso per impostare l'ambiente

32

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 si tratta di una pratica buona o cattiva, e penso che sia una cattiva pratica, perché dobbiamo evitare questo tipo di codice e impostare una corretta configurazione. Ma ad essere sincero, non conosco davvero la risposta corretta e perché non è raccomandato e qual è il modo corretto di implementarlo.

qualcuno può spiegare i pro e i contro della pratica di cui sopra?

— gon250
fonte

13

Questa riga da sola non è ottimale. path = " yourpath.com "; La configurazione dovrebbe essere esterna al codice.

— paparazzo,

2

Dal punto di vista della revisione del codice, a Dictionaryè un modo molto più pulito di codificare questo in C #. Vedi ideone.com/45g5xO . O in JS usa un oggetto vecchio, vedi jsfiddle.net/1ouhovqq .

— Danny Beckett,

4

cosa succede se il nome della tua azienda cambia in qualcosa che contiene "qa"?

— user253751

Ricorda che se si utilizza un file di configurazione, è necessario controllarlo nel controllo del codice sorgente .... Qualunque potrebbe essere necessario modificare il file di configurazione più volte al giorno quando si impostano nuove macchine di prova. Penso ancora che un file di configurazione sia il migliore, ma potresti voler prima cercare un file chiamato Environment, prima di guardare il file di configurazione detaul.

— Ian,

1

Non penso che dovresti andare in giro a chiamare cose cattive pratiche se non riesci a quantificare perché pensi che sia una cattiva pratica

— Roy

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 "buone pratiche" se quella persona non è in grado di indicare qual è il problema con il tuo codice.

In questo caso, il problema più evidente è che le risorse sono codificate nell'applicazione - anche se sono selezionate in modo dinamico, sono ancora codificate. Ciò significa che non è possibile modificare queste risorse senza ricompilare / ridistribuire l'applicazione. Con un file di configurazione esterno, dovrai solo modificare quel file e riavviare / ricaricare l'applicazione.

Se questo è un problema dipende da cosa ci fai. In un framework Javascript che viene comunque ridistribuito automaticamente con ogni richiesta, non è affatto un problema: il valore modificato si propaga a tutti gli utenti 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 deve essere fatta di notte per preservare la disponibilità.

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

— Kilian Foth
fonte

15

Adoro il tuo primo paragrafo. Certo, lo segui con ... sottolineando quali sono i problemi ... ma l'idea che "questo è male perché il blog XYZ lo ha detto" è la causa di un codice più cattivo di quello che effettivamente impedisce.

— corsiKa

5

Ai principianti dovrebbero essere dati principi testati nel tempo per vivere, non semplicemente "se funziona per te, allora va bene" relativismo. Immagino di non avere torto nel dire che i valori ambientali che codificano duramente sono delle cattive pratiche sotto ogni punto di vista.

— Tulains Córdova,

3

@ jpmc26: Stai ovviamente supponendo che la distribuzione del codice lato server non sia banale e che ci sia un processo separato attraverso il quale i valori di configurazione possono essere aggiornati con un sovraccarico minore. Nessuno dei due è necessariamente vero. Molti negozi hanno pochissime spese generali nei loro processi di distribuzione. D'altra parte, in realtà ci sono alcuni negozi in cui le modifiche alla configurazione hanno sostanzialmente lo stesso sovraccarico della distribuzione del codice modificato. (Convalida, necessita dell'approvazione di un sacco di persone, ecc.). Le preoccupazioni sulla duplicazione sono comunque valide.

— Kevin Cathcart,

2

Con le impostazioni dell'ambiente mescolate al tuo codice dell'applicazione, sei un errore logico - o una modifica imprevista nell'ambiente di esecuzione - lontano dal colpire il test dalla produzione o dalla produzione dal test o da qualche altra combinazione imprevista e possibilmente catastrofica. Mantenere le proprietà specifiche dell'ambiente separate dal codice in C # è generalmente banale. Perché correre un rischio non necessario?

— John M Gant,

1

@ user61852 "Immagino di non sbagliare nel dire che i valori di ambiente con codifica rigida sono decisamente cattive pratiche sotto qualsiasi luce." analizza "i valori dell'ambiente con codifica rigida sono sempre una cattiva pratica" Se è sempre una cattiva pratica, allora dovrebbe essere sempre possibile identificare almeno un problema che causeranno i valori dell'ambiente con codifica rigida.

— emory

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 si desidera aggiungere un altro ambiente? O cambiare il tuo server di sviluppo? O è necessario eseguire il failover in una posizione diversa? Non puoi perché la tua configurazione è direttamente legata al codice.

La configurazione dovrebbe essere forzata al di fuori del codice e nell'ambiente stesso. È un principio di un'app Twelve-Factor ( http://12factor.net/config ), ma è una buona pratica per qualsiasi applicazione. Potresti scoprire che le variabili di ambiente non sono appropriate alla tua situazione, nel qual caso ti suggerirei di cercare di archiviare quella configurazione in un database di file di configurazione insieme al codice (ma non verificato con).

— mgw854
fonte

Se non tieni traccia del file di configurazione, come fai a sapere se il file di configurazione che hai è valido per la versione del software che hai appena estratto dal tuo VCS. (ovvero un file di configurazione non tracciato non è diverso da un file sorgente non

— tracciato

Non sono d'accordo sul fatto che un file di configurazione non tracciato sia una proposta difficile. Il modo in cui l'ho affrontato in precedenza è duplice: uno, il binario per la distribuzione contiene anche uno schema XML che ne definisce la configurazione (in modo da poter verificare che un determinato file di configurazione funzioni). In secondo luogo, i file di configurazione per ciascun ambiente sono stati archiviati in un sistema di controllo dei documenti con cartelle diverse per ciascun ambiente. Qualcosa di simile potrebbe essere fatto in Git con rami - versione controllata, ma discriminata dal codice senza ambiente.

— mgw854,

5

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

Come indicato 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 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). Esistono diversi modi per farlo a seconda della lingua. Uno dei più semplici (di solito) è semplicemente impostare le variabili di ambiente. Quindi basta modificare le variabili a seconda di dove si sta eseguendo, che si tratti di una casella di sviluppo locale, qa o produzione. Un'altra opzione è la memorizzazione dei valori in un .inifile o JSON. Un'altra alternativa sarebbe la memorizzazione dei valori di configurazione come codice effettivo. A seconda della lingua o dell'ambiente che stai utilizzando, questa potrebbe essere o meno una buona idea.

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.

— Wayne Werner
fonte

1

Cosa succede se desidero eseguire il backend sul mio computer ma non sulla porta 55793, ad esempio se stavo eseguendo più versioni contemporaneamente per confrontarle? Cosa succede se desidero eseguire il back-end dell'applicazione su un computer, ma accedervi da un altro? Cosa succede se desidero aggiungere un quarto ambiente? Come altri hanno sottolineato, devi ricompilare solo per cambiare la configurazione di base.

L'approccio che hai descritto potrebbe aver funzionato nella pratica finora per la tua squadra, 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 quali vantaggi si ottiene con l'approccio switch switch? Nessuna!

— PeterAllenWebb
fonte

0

È UNA CATTIVA PRATICA .

Un principio di base della progettazione del software: non codificare i valori di configurazione all'interno dei programmi. Ciò è particolarmente vero per qualsiasi cosa che abbia ragionevoli possibilità di cambiare in futuro.

Il codice del programma sviluppato deve essere lo stesso codice presente in qualsiasi ambiente come test QA, UAT e produzione. Se qualcuno ha bisogno di cambiare la configurazione in un secondo momento perché l'ambiente è cambiato, o devono usarlo in un nuovo ambiente, va bene. Ma non dovrebbero mai toccare il codice del programma per farlo. E non dovresti avere versioni diverse di codice per ogni ambiente. Se il tuo programma è cambiato da quando è stato testato, allora non hai provato quella versione. Chiedere a qualsiasi ingegnere informatico, qualsiasi professionista della garanzia della qualità del software, qualsiasi professionista della gestione di progetti IT, qualsiasi revisore IT.

Qualcuno potrebbe spostare i test su un altro server. Qualcuno potrebbe decidere di voler anche un ambiente di formazione per l'utente o un ambiente per dimostrazioni di vendita. Non dovrebbero andare da un programmatore per la configurazione amministrativa.

Il software dovrebbe essere abbastanza flessibile e robusto per 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 è piccolo rispetto al costo della manutenzione del software per tutta la sua durata. E diciamo che tra un anno potresti non essere la persona che lavora su quel codice. Dovresti pensare a cosa stai lasciando per il prossimo povero idiota che deve raccogliere tutto il disordine che potresti aver lasciato alle spalle, forse anni dopo che sei passato a pascoli più verdi. Oppure potresti essere colui che prende 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 in seguito.

— warrent
fonte