Má prática - alternar entre maiúsculas e minúsculas para definir o ambiente

Nos últimos três anos em que trabalhei como desenvolvedor, vi muitos exemplos em que as pessoas usam uma instrução switch para definir o caminho (tanto no back-end quanto no front-end) para um URL. Abaixo está um exemplo disso:

Exemplo de backend (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;
}

Exemplo de 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/";
    }
})();

Foi discutido se é uma prática boa ou ruim, e acho que é uma prática ruim, porque devemos evitar esse tipo de código e definir uma configuração adequada. Mas, para ser sincero, eu realmente não sei a resposta correta e por que ela não é recomendada e qual é a maneira correta de implementar isso.

alguém pode explicar os prós e os contras da prática acima?

O código que funciona para você e é fácil de manter é, por definição, "bom". Você nunca deve mudar as coisas apenas por obedecer à idéia de "boa prática" de alguém, se essa pessoa não puder apontar qual é o problema do seu código.

Nesse caso, o problema mais óbvio é que os recursos são codificados em seu aplicativo - mesmo que sejam selecionados dinamicamente, eles ainda são codificados. Isso significa que você não pode alterar esses recursos sem recompilar / reimplementar seu aplicativo. Com um arquivo de configuração externo, você apenas precisará alterar esse arquivo e reiniciar / recarregar seu aplicativo.

Se isso é ou não um problema, depende do que você faz com ele. Em uma estrutura Javascript que é redistribuída automaticamente a cada solicitação, não há problema algum - o valor alterado será propagado para todos os usuários na próxima vez em que usarem o aplicativo. Com uma implantação local em uma linguagem compilada em um local inacessível, é realmente um grande problema. A reinstalação do aplicativo pode levar muito tempo, custar muito dinheiro ou ter que ser feita à noite para preservar a disponibilidade.

Se os valores codificados são ou não um problema depende se sua situação é mais parecida com o primeiro exemplo ou mais com o segundo exemplo.

Você está absolutamente certo ao pensar que esta é uma má prática. Eu já vi isso no código de produção, e ele sempre volta para te morder.

O que acontece quando você deseja adicionar outro ambiente? Ou mudar seu servidor de desenvolvimento? Ou você precisa fazer o failover para um local diferente? Você não pode porque sua configuração está diretamente vinculada ao código.

A configuração deve ser forçada a sair do código e entrar no próprio ambiente. É um princípio de um aplicativo de doze fatores ( http://12factor.net/config ), mas é uma boa prática para qualquer aplicativo. Você pode achar que as variáveis ​​de ambiente não são apropriadas para a sua situação; nesse caso, sugiro que você armazene essa configuração em um banco de dados de arquivo de configuração ao lado do código (mas não com o check-in).

Por um lado, (como outros já mencionaram), é uma má idéia, porque você está vinculando detalhes da implementação ao seu código. Isso torna difícil mudar as coisas.

Conforme mencionado nesta resposta , se você deseja adicionar um novo ambiente agora, é necessário atualizar seu código em qualquer lugar , em vez de apenas adicionar seu programa a um novo ambiente.

Existe outra falha grave ao fazer isso no seu código Javascript: você está expondo os internos da sua empresa a possíveis invasores. Claro, você pode estar protegido por um firewall, mas ainda pode ter um funcionário insatisfeito ou alguém que liberta um vírus.

Más notícias.

A melhor coisa a fazer é definir sua configuração a partir do ambiente (como na resposta vinculada anteriormente, o Twelve-Factor App oferece ótimos conselhos sobre o assunto). Existem várias maneiras de fazer isso, dependendo do seu idioma. Um dos mais fáceis (geralmente) é apenas definir variáveis ​​de ambiente. Depois, basta alterar as variáveis, dependendo de onde você está executando - seja uma caixa de desenvolvimento local, qa ou produção. Outra opção é armazenar os valores em um.ini arquivo ou JSON. Outra alternativa seria armazenar seus valores de configuração como código real. Dependendo do idioma ou do ambiente em uso, isso pode ou não ser uma boa ideia.

Mas o objetivo final é permitir que você use uma base de código, solte-a em qualquer máquina com arquitetura / conectividade suportada e possa executá-la sem modificar o código de nenhuma maneira.

E se eu quiser executar o back-end em minha própria máquina, mas não na porta 55793, por exemplo, se eu estiver executando várias versões ao mesmo tempo para compará-las? E se eu quiser executar o back-end do aplicativo em uma máquina, mas acessá-lo de outra? E se eu quiser adicionar um quarto ambiente? Como outros já apontaram, você deve recompilar apenas para alterar a configuração básica.

A abordagem que você descreveu pode ter funcionado na prática para sua equipe até agora, mas é inútil e restritiva. Um sistema de configuração que permite que parâmetros como esse caminho sejam definidos arbitrariamente em um arquivo de configuração central é muito mais flexível do que um que fornece apenas opções fixas, e que vantagem você ganha com a abordagem da instrução switch? Nenhum!

É uma má prática .

Um princípio básico do design de software: não codifique valores de configuração dentro de seus programas. Isto é especialmente verdade para qualquer coisa que tenha uma chance razoável de mudar no futuro.

O código do programa que você desenvolve deve ser o mesmo código que entra em qualquer ambiente, como teste de controle de qualidade, UAT e produção. Se alguém precisar alterar a configuração posteriormente porque o ambiente mudou ou precisar usá-la em um novo ambiente, tudo bem. Mas eles nunca devem tocar no código do seu programa para fazer isso. E você não deve ter versões diferentes de código para cada ambiente. Se o seu programa mudou desde que foi testado, você não testou essa versão. Pergunte a qualquer engenheiro de software, qualquer profissional de controle de qualidade de software, qualquer profissional de gerenciamento de projetos de TI, qualquer auditor de TI.

Alguém pode mover o teste para outro servidor. Alguém pode decidir também querer um ambiente de treinamento do usuário ou um ambiente para demonstrações de vendas. Eles não precisam ir a um programador para configuração administrativa.

O software deve ser flexível e robusto o suficiente para lidar com situações inesperadas, dentro do razoável.

Além disso, o software não deve ser escrito simplesmente, no entanto, parece mais fácil para você no momento. O custo do desenvolvimento de software é pequeno comparado ao custo de manutenção de software ao longo de sua vida útil. E digamos que daqui a um ano, você pode não ser a pessoa que trabalha nesse código. Você deve estar pensando no que está deixando para o próximo pobre tolo que tem que pegar qualquer bagunça que tenha deixado para trás, talvez anos depois de ter passado por pastos mais verdes. Ou você pode ser o único que pega o código anos depois, sem acreditar no que fez na época.

Codifique as coisas corretamente, da melhor maneira possível. É menos provável que se torne um problema mais tarde.