Mala práctica: cambiar la carcasa para establecer el entorno

32

En los últimos tres años que he trabajado como desarrollador, he visto muchos ejemplos en los que las personas usan una declaración de cambio para establecer la ruta (tanto en el back-end como en el front-end) para una URL. A continuación se muestra un ejemplo de esto:

Ejemplo de fondo (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;
}

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

Se ha discutido si es una buena o mala práctica, y creo que es una mala práctica, porque debemos evitar este tipo de código y establecer una configuración adecuada. Pero para ser honesto, realmente no sé la respuesta adecuada y por qué no se recomienda y cuál es la forma correcta de implementar esto.

¿Alguien puede explicar los pros y los contras de la práctica anterior?

— gon250
fuente

13

Esta línea por sí sola no es óptima. ruta = " yourpath.com "; La configuración debe ser externa al código.

— paparazzo

2

Desde una perspectiva de revisión de código puro, a Dictionaryes una forma mucho más limpia de codificar esto en C #. Ver ideone.com/45g5xO . O en JS use un objeto antiguo, vea jsfiddle.net/1ouhovqq .

— Danny Beckett

44

¿Qué sucede si el nombre de su empresa cambia a algo que contiene "qa"?

— user253751

Recuerde que si usa un archivo de configuración, debe controlarse en el control del código fuente ... Puede que tenga que editar el archivo de configuración muchas veces al día cuando configure nuevas máquinas de prueba. Todavía creo que un archivo de configuración es lo mejor, pero es posible que desee buscar primero un archivo llamado Entorno basado antes de mirar el archivo de configuración detaul.

— Ian

1

No creo que debas decir que las cosas son malas prácticas si no puedes cuantificar por qué piensas que es una mala práctica

— Roy

81

El código que funciona para usted y es fácil de mantener es, por definición, "bueno". Nunca debe cambiar las cosas solo por el hecho de obedecer la idea de "buena práctica" de alguien si esa persona no puede señalar cuál es el problema con su código.

En este caso, el problema más obvio es que los recursos están codificados en su aplicación, incluso si se seleccionan dinámicamente, todavía están codificados. Esto significa que no puede cambiar estos recursos sin volver a compilar / volver a implementar su aplicación. Con un archivo de configuración externo, solo tendría que cambiar ese archivo y reiniciar / volver a cargar su aplicación.

Si eso es o no un problema depende de lo que hagas con él. En un marco Javascript que se redistribuye automáticamente con cada solicitud de todos modos, no hay ningún problema en absoluto: el valor modificado se propagará a cada usuario la próxima vez que use la aplicación. Con una implementación local en un idioma compilado en una ubicación inaccesible, es un gran problema. La reinstalación de la aplicación puede llevar mucho tiempo, costar mucho dinero o tener que hacerse por la noche para preservar la disponibilidad.

El hecho de que los valores codificados sean un problema o no depende de si su situación se parece más al primer ejemplo o más al segundo ejemplo.

— Kilian Foth
fuente

15

Me encanta tu primer párrafo. Claro, lo sigues con ... señalando cuáles son los problemas ... pero la idea de que "esto es malo porque el blog XYZ lo dijo" es la causa de más código incorrecto del que realmente evita.

— corsiKa

55

A los principiantes se les deben dar principios probados para vivir, no simplemente "si funciona para ti, entonces está bien" el relativismo. Supongo que no me equivoco al decir que codificar los valores del entorno es una mala práctica bajo cualquier concepto.

— Tulains Córdova

3

@ jpmc26: Por supuesto, está asumiendo que la implementación del código del lado del servidor no es trivial, y también que hay un proceso separado a través del cual los valores de configuración se pueden actualizar con menos sobrecarga. Ninguno de los dos es necesariamente cierto. Muchas tiendas tienen muy poca sobrecarga en sus procesos de implementación. Por otro lado, en realidad hay algunas tiendas donde los cambios de configuración tienen básicamente tanta sobrecarga como implementar el código modificado. (Validación, necesita la aprobación de un montón de personas, etc.). Sin embargo, las preocupaciones de duplicación son definitivamente válidas.

— Kevin Cathcart

2

Con la configuración del entorno mezclada con el código de su aplicación, usted es un error lógico, o un cambio no anticipado en el entorno de ejecución, lejos de alcanzar la prueba de producción, o la producción de prueba, o alguna otra combinación inesperada y posiblemente catastrófica. Mantener propiedades específicas del entorno separadas del código en C # es generalmente trivial. ¿Por qué correr un riesgo innecesario?

— John M Gant

1

@ user61852 "Supongo que no me equivoco al decir que codificar los valores del entorno es una mala práctica bajo cualquier concepto". analiza "los valores del entorno de codificación dura son siempre una mala práctica" Si siempre es una mala práctica, siempre debería ser posible identificar al menos un problema que causarán los valores del entorno de codificación dura.

— emory

14

Tienes toda la razón al pensar que esta es una mala práctica. He visto esto en el código de producción, y siempre vuelve a morderte.

¿Qué sucede cuando quieres agregar otro entorno? ¿O cambiar su servidor de desarrollo? ¿O necesita fallar a una ubicación diferente? No puede porque su configuración está directamente vinculada al código.

La configuración debe ser forzada a salir del código y al entorno mismo. Es un principio de una aplicación de doce factores ( http://12factor.net/config ), pero es una buena práctica para cualquier aplicación. Puede encontrar que las variables de entorno no son apropiadas para su situación, en cuyo caso sugeriría buscar almacenar esa configuración en una base de datos del archivo de configuración junto con el código (pero no registrado).

— mgw854
fuente

Si no realiza un seguimiento del archivo de configuración, ¿cómo sabe si el archivo de configuración que tiene es válido para la versión de software que acaba de extraer de su VCS? (es decir, un archivo de configuración no rastreado no es diferente a un archivo de origen no rastreado; no puede compilar e implementar desde el pago de VCS sin él)

— mattnz

No estoy de acuerdo con que un archivo de configuración sin seguimiento sea una propuesta difícil. La forma en que he tratado esto es doble: una, el binario para la implementación también contiene un Esquema XML que define su configuración (para que pueda verificar que un archivo de configuración dado funcionará). En segundo lugar, los archivos de configuración para cada entorno se almacenaron en un sistema de control de documentos con diferentes carpetas para cada entorno. Algo similar se podría hacer en Git con ramas: versión controlada, pero discriminada del código sin entorno.

— mgw854

5

Por un lado, (como han mencionado otros), esta es una mala idea porque está vinculando detalles de implementación en su código. Esto hace que sea difícil cambiar las cosas.

Como se menciona en esta respuesta , si desea agregar un nuevo entorno ahora debe actualizar su código en todas partes , en lugar de simplemente agregar su programa a un nuevo entorno.

Hay otra falla grave al hacer esto en su código Javascript: está exponiendo los elementos internos de su empresa a posibles atacantes. Claro, puede estar detrás de un firewall, pero aún puede tener un empleado descontento o alguien que deja entrar un virus.

Malas noticias osos.

Lo mejor que puede hacer es establecer su configuración desde el entorno (como en la respuesta vinculada anteriormente, la aplicación Twelve-Factor tiene excelentes consejos sobre el tema). Hay varias formas de hacer esto dependiendo de su idioma. Una de las más fáciles (generalmente) es simplemente establecer variables de entorno. Luego simplemente cambia las variables dependiendo de dónde se está ejecutando, ya sea un cuadro de desarrollo local, qa o producción. Otra opción es almacenar los valores en un .iniarchivo o JSON. Otra alternativa sería almacenar sus valores de configuración como código real. Dependiendo de qué idioma o entorno esté utilizando, esto puede o no ser una buena idea.

Pero el objetivo final es permitirle tomar una base de código, soltarla en cualquier máquina que tenga la arquitectura / conectividad compatible y poder ejecutarla sin modificar el código de ninguna manera.

— Wayne Werner
fuente

1

¿Qué sucede si quiero ejecutar el back-end en mi propia máquina pero no en el puerto 55793, por ejemplo si ejecutaba varias versiones al mismo tiempo para compararlas? ¿Qué sucede si quiero ejecutar el backend de la aplicación en una máquina, pero acceder a ella desde otra? ¿Qué pasa si quiero agregar un cuarto entorno? Como otros han señalado, debe volver a compilar solo para cambiar la configuración básica.

El enfoque que ha descrito podría haber funcionado en la práctica para su equipo hasta ahora, pero es inútilmente restrictivo. Un sistema de configuración que permite que parámetros como esta ruta se establezcan arbitrariamente en un archivo de configuración central es mucho más flexible que uno que solo proporciona opciones fijas, y ¿qué ventaja obtiene con el enfoque de declaración de cambio? ¡Ninguna!

— PeterAllenWebb
fuente

0

Es una MALA PRÁCTICA .

Un principio básico del diseño de software: no codifique valores de configuración dentro de sus programas. Esto es especialmente cierto para cualquier cosa que tenga una posibilidad razonable de cambiar en el futuro.

El código de programa que desarrolle debe ser el mismo código que se aplica a cualquier entorno, como pruebas de control de calidad, UAT y producción. Si alguien necesita cambiar la configuración más tarde porque el entorno ha cambiado, o si necesita usarlo en un nuevo entorno, está bien. Pero nunca deberían tener que tocar el código de su programa para hacerlo. Y no debe tener diferentes versiones de código para cada entorno. Si su programa ha cambiado desde que se probó, entonces no ha probado esa versión. Pregúntele a cualquier ingeniero de software, a cualquier profesional de garantía de calidad de software, a cualquier profesional de gestión de proyectos de TI, a cualquier auditor de TI.

Alguien podría mover las pruebas a otro servidor. Alguien podría decidir si también desea un entorno de capacitación de usuarios o un entorno para demostraciones de ventas. No deberían tener que ir a un programador para la configuración administrativa.

El software debe ser lo suficientemente flexible y robusto para manejar situaciones inesperadas, dentro de lo razonable.

Además, el software no debe escribirse simplemente, sin embargo, parece más fácil para usted en este momento. El costo del desarrollo del software es pequeño en comparación con el costo del mantenimiento del software durante su vida útil. Y digamos que dentro de un año, es posible que no seas la persona que trabaja en ese código. Deberías estar pensando en lo que estás dejando para el próximo tonto pobre que tiene que recoger cualquier desastre que hayas dejado atrás, tal vez años después de que hayas pasado a pastos más verdes. O puede ser usted quien recoja el código años después, sin creer lo que hizo en ese momento.

Codifique las cosas correctamente, lo mejor que pueda. Es menos probable que se convierta en un problema más tarde.

— WarrenT
fuente