¿Los archivos de configuración externos se consideran antipatrones?

Muchas veces he estado en una situación en la que aparentemente una aplicación está rota, solo para descubrir que un archivo de configuración externo ha tenido la culpa. Por lo general, esto se debe a que hay un archivo incorrecto o que contiene datos incorrectos.

¿Existe una mejor manera de permitir que un usuario / proceso externo modifique las características de tiempo de ejecución de una aplicación, o esta es la solución más conocida para el problema?

Me gustaría ver una discusión sobre el caso general en lugar de centrarme, por ejemplo, en Unix /etc o Java JNDI, etc.

La mayoría de las aplicaciones requerirán alguna configuración externa; puede ocultar esto haciéndolo dependiente de variables mágicas, o guardándolo en alguna ubicación interna, pero eso no eliminará la necesidad. El objetivo es reconocer lo que debería ser externo y lo que puede ser interno. Solo se pueden probar las partes internas.

Una aplicación no debe confiar en que un archivo de configuración externo sea correcto. Debe verificar la corrección e informar errores. Si no es posible que la aplicación verifique el archivo de configuración, probablemente esté haciendo demasiado con él. Si el archivo de configuración cambia el comportamiento de la aplicación, no debería ser externo en mi opinión.

Por ejemplo, la aplicación puede verificar fácilmente un nombre de usuario / contraseña de la base de datos al intentar conectarse a la base de datos. Si esto falla, puede informarlo, y obviamente no es un error en el código de la aplicación. Del mismo modo, para una ruta de archivo se pueden verificar los derechos de existencia y acceso.

Ahora, si tuviera que poner consultas SQL en el archivo de configuración, entonces la aplicación no puede verificar fácilmente la exactitud de esas consultas. Lo mismo ocurre con un archivo de especificación de inyección de dependencia completa (a la Java-Spring XML). Esos no deberían estar en archivos de configuración externos.

Pero si la configuración especificada describe algo externo, y puede verificar rápidamente su corrección, no creo que haya ningún problema con los archivos de configuración externos.

Editar: también asegúrese de que sus informes de error muestren qué archivo de configuración se utiliza. Nada es más frustrante que descubrir que estaba buscando el archivo incorrecto después de horas de tratar de averiguar qué le pasa.

Los clasificaría más como un "área problemática conocida" que como un antipatrón. A menos que vaya a implementar una configuración fija, tendrá que almacenar información de configuración en algún lugar . Por lo general, me gusta almacenar la mayor parte de mi información de configuración en la base de datos, pero aún tiene que almacenar la información de conexión de la base de datos en algún lugar. Prefiero el enfoque Java / Spring de almacenar la información de configuración en la estructura de la aplicación en lugar de (por ejemplo) en el directorio de inicio del usuario o el registro de Windows, pero eso es solo una preferencia personal.

Los archivos de configuración externos NO son un antipatrón. Como todo lo demás, pueden usarse bien o mal dependiendo del sistema en cuestión.

Parece que se ha encontrado con algunas aplicaciones donde la configuración externa puede romper la aplicación sin decirle al usuario lo que está sucediendo. Eso es malo, pero no es culpa de los archivos de configuración, es culpa de quien decidió qué partes están en los archivos de configuración y qué partes están en la aplicación, y cómo manejar los errores entre ellos.

En mi opinión: NO , los archivos de configuración externos no son un antipatrón.

Es solo una técnica, un patrón arquitectónico para administrar la complejidad del software.

En la era de los principios de diseño SOLID , ha trasladado la complejidad del software de Monolithic_application a módulos más independientes que deben conectarse entre sí.

la alternativa a los "archivos de configuración externos" sería configurar los módulos directamente por código.

En todo caso, se prefiere mover la configuración de la lógica a los datos. Le permite hacer que la aplicación sea más flexible sin la necesidad de modificar su código. La falta de archivos de datos es más un caso de muy poca documentación o trabajo descuidado durante la instalación que una mala práctica en términos de codificación en mi humilde opinión.

Haga que su herramienta SCM favorita cumpla una doble función como herramienta CM: coloque sus archivos de configuración en el repositorio. Para cambiar la configuración, confirme los cambios y deje que sus herramientas de implementación automatizadas las envíen a producción (después de ejecutar una serie de pruebas automatizadas, ¡por supuesto!)

Et Voila! ¡tiene un registro de todos los cambios de configuración, más la red de seguridad adicional de un sistema automatizado de CI / prueba!

Como se ha señalado anteriormente, los patrones de arquitectura y diseño no se limitan al sistema del producto en sí, sino que también se extienden al equipo / proceso / sistemas que ayudan a producirlo.