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?
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 .Respuestas:
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.
fuente
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).
fuente
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.
fuente
¿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!
fuente
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.
fuente