¿En qué momento un archivo de configuración se convierte en un lenguaje de programación?

He estado reflexionando sobre los archivos de configuración y su relación con el código durante un tiempo y, dependiendo del día y la dirección del viento, mis opiniones parecen cambiar. Más y más, aunque sigo volviendo a la conclusión que tuve por primera vez mientras aprendía Lisp: hay poca diferencia entre los datos y el código. Esto parece doblemente cierto para los archivos de configuración. Cuando se mira con la luz adecuada, un script de Perl es poco más que un archivo de configuración para Perl. Esto tiende a tener consecuencias bastante graves para tareas como el control de calidad y las divisiones de trabajo, como quién debería ser responsable de cambiar los archivos de configuración.

El paso del archivo de configuración al lenguaje completo es generalmente lento y parece estar impulsado por el deseo de tener un sistema genérico. La mayoría de los proyectos parecen comenzar pequeños con algunos elementos de configuración como dónde escribir registros, dónde buscar datos, nombres de usuario y contraseñas, etc. Pero luego comienzan a crecer: las características comienzan a poder activarse o desactivarse, los tiempos y el orden de las operaciones comienzan a ser controlados e, inevitablemente, alguien quiere comenzar a agregarle lógica (por ejemplo, use 10 si la máquina es X y 15 si la máquina es Y). En cierto punto, el archivo de configuración se convierte en un lenguaje específico de dominio y, además, en uno mal escrito.

Ahora que he divagado para preparar el escenario, estas son mis preguntas:

1. ¿Cuál es el verdadero propósito de un archivo de configuración?
2. ¿Se debe intentar mantener los archivos de configuración simples?
3. ¿Quién debería ser responsable de realizar cambios en ellos (desarrolladores, usuarios, administradores, etc.)?
4. ¿Deberían ser controlados en fuente (ver pregunta 3)?

Como dije antes, mis respuestas a estas preguntas cambian constantemente, pero ahora mismo estoy pensando:

1. Permitir a los no programadores cambiar rápidamente grandes porciones de comportamiento
2. sí, todo lo que no sea de grano grueso debe estar en código
3. los usuarios deben ser responsables de los archivos de configuración y los programadores deben ser responsables de una capa de configuración entre los archivos de configuración y el código que brinde un control más detallado de la aplicación
4. no, pero la capa intermedia de grano más fino debe ser

¡Preguntas muy interesantes!

Tiendo a limitar mis archivos de configuración a un formato "clave = valor" muy simple, porque estoy totalmente de acuerdo con usted en que los archivos de configuración pueden convertirse muy rápidamente en programas completos. Por ejemplo, cualquiera que haya intentado "configurar" OpenSER conoce la sensación de la que estás hablando: no es configuración, es (doloroso) programación.

Cuando necesita que su aplicación sea muy "configurable" de formas que no puede imaginar hoy, entonces lo que realmente necesita es un sistema de complementos . Necesita desarrollar su aplicación de manera que otra persona pueda codificar un nuevo complemento y conectarlo a su aplicación en el futuro.

Entonces, para responder a sus preguntas:

1. ¿Cuál es el verdadero propósito de un archivo de configuración?

   Yo diría, para permitir que las personas que instalarán su aplicación puedan modificar algunos parámetros relacionados con la implementación, como el nombre de host, la cantidad de subprocesos, los nombres de los complementos que necesita y los parámetros de implementación para esos complementos (verifique Fuera la configuración de FreeRadius para un ejemplo de este principio), etc. Definitivamente no es el lugar para expresar la lógica empresarial.

2. ¿Se debe intentar mantener los archivos de configuración simples?

   Seguro. Como sugirió, "programar" en un archivo de configuración es horrible. Creo que debería evitarse.

3. ¿Quién debería ser responsable de realizar cambios en ellos (desarrolladores, usuarios, administradores, etc.)?

   En general, diría administradores, que implementan la aplicación.

4. ¿Deberían ser controlados en fuente (ver pregunta 3)?

   Por lo general, no controlo el origen de los archivos de configuración, pero sí controlo el origen de un archivo de configuración de plantilla, con todos los parámetros y sus valores predeterminados, y comentarios que describen lo que hacen. Por ejemplo, si se nombra un archivo de configuración database.conf, normalmente controlo la fuente de un archivo llamado database.conf.template. Ahora, por supuesto, estoy hablando de lo que hago como desarrollador . Como administrador , es posible que desee controlar la fuente de la configuración real que elegí para cada instalación. Por ejemplo, administramos algunos cientos de servidores de forma remota y necesitamos realizar un seguimiento de sus configuraciones: elegimos hacer esto con control de fuente.

Editar: Aunque creo que lo anterior es cierto para la mayoría de las aplicaciones, siempre hay excepciones, por supuesto. Su aplicación puede permitir a sus usuarios configurar dinámicamente reglas complejas, por ejemplo. La mayoría de los clientes de correo electrónico permiten a los usuarios definir reglas para la gestión de sus correos electrónicos (por ejemplo, "todos los correos electrónicos que provienen de 'john doe' y no me tienen en el campo Para: deben descartarse"). Otro ejemplo es una aplicación que permite al usuario definir una nueva oferta comercial compleja. También puede pensar en aplicaciones como Cognos que permiten a sus usuarios crear informes de bases de datos complejos. El cliente de correo electrónico probablemente ofrecerá al usuario una interfaz simple para definir las reglas, y esto generará un archivo de configuración complejo (o incluso quizás un poco de código). Por otra parte, la configuración definida por el usuario para las ofertas comerciales puede guardarse en una base de datos, de forma estructurada (ni una estructura simple clave = valor ni una porción de código). Y algunas otras aplicaciones incluso pueden permitir al usuario codificar en python o VB, o en algún otro lenguaje con capacidad de automatización. En otras palabras ... su kilometraje puede variar.

Okay. Tendrás algunos usuarios que quieran una configuración realmente simple, deberías dársela. Al mismo tiempo, tendrás solicitudes constantes de "¿Puedes agregar esto? ¿Cómo lo hago en el archivo de configuración?", No veo por qué no puedes admitir ambos grupos.

El proyecto en el que estoy trabajando actualmente usa Lua para su archivo de configuración. Lua es un lenguaje de scripting y funciona bastante bien en este escenario. Hay disponible un ejemplo de nuestra configuración predeterminada .

Notarás que se trata principalmente de declaraciones clave = valor, donde valor puede ser cualquiera de los tipos integrados de Lua. Lo más complicado que hay son las listas, y no son realmente complicadas (es solo una cuestión de sintaxis).

Ahora solo estoy esperando que alguien pregunte cómo configurar el puerto de su servidor en un valor aleatorio cada vez que lo inician ...

Recientemente estaba trabajando en un proyecto y me di cuenta de que quería tener condicionales dentro de mi archivo de configuración, que anteriormente había sido bastante simple de la forma:

key = val
key2 = val
name = `hostname`

No quería escribir un mini-lenguaje, porque a menos que lo hiciera con mucho cuidado no podría permitir la flexibilidad que sería útil.

En cambio, decidí que tendría dos formas:

1. Si el archivo comenzó con "#!" y era ejecutable analizaría el resultado de ejecutarlo.

2. De lo contrario, lo leería tal cual

Esto significa que ahora puedo permitir que las personas escriban "archivos de configuración" con este aspecto:

 #!/usr/bin/perl
if ( -x /bin/foo ) 
{
   print <<EOF;
foo=me
bar=you
EOF
}
else
{
   print <<EOF;
foo=bar
bar=foo
EOF
}

De esta manera obtengo el poder de un archivo de configuración dinámica si el usuario quiere usarlo, y la simplicidad de no tener que escribir mi propio mini-lenguaje.

Cada esquema de archivo de configuración (suficientemente duradero) eventualmente se convierte en un lenguaje de programación. Debido a todas las implicaciones que describe, es aconsejable que el diseñador del archivo de configuración se dé cuenta de que está creando un lenguaje de programación y planifique en consecuencia, para que no cargue a los usuarios futuros con un legado incorrecto.

Tengo una filosofía diferente sobre los archivos de configuración. Los datos sobre cómo se debe ejecutar una aplicación siguen siendo datos y, por lo tanto, pertenecen a un almacén de datos, no a un código (un archivo de configuración en mi opinión es código). Si los usuarios finales necesitan poder cambiar los datos, la aplicación debe proporcionar una interfaz para hacerlo.

Solo uso archivos de configuración para apuntar a almacenes de datos.

Podría recurrir a la teoría de la computación para definir qué cuenta como lenguaje de programación. Si su formato de archivo de configuración es Turing Complete , razonablemente cuenta como un lenguaje de programación. Según esta definición, un formato de archivo para describir niveles de Sokoban cuenta como lenguaje de programación (ver aquí ). Hay otros niveles de complejidad debajo de Turing Complete que también pueden contar, como las Gramáticas regulares y Pushdown Automata .

Otra forma de verlo es que muchos archivos de configuración solo son capaces de marcar datos, mientras que un lenguaje de programación adecuado debe poder implementar algoritmos . Por ejemplo, JSON es un formato de archivo de configuración, mientras que ECMA Script es un lenguaje de programación.

Estos son mis pensamientos:

1. Permitir modificar fácilmente el comportamiento en tiempo de ejecución de una aplicación. Esto puede ser por programadores o no programadores, según las necesidades. Esto puede ser durante el desarrollo, pero a menudo veo los archivos de configuración como una forma de ayudar a que un programa sea más flexible en cualquier momento.

2. Si. Creo que los archivos de configuración deberían ser lo más simples posible, dada la restricción de que es posible que necesite varias opciones para controlar diferentes comportamientos de su tiempo de ejecución. Prefiero agrupar los ajustes de configuración y simplificarlos tanto como sea posible.

3. Depende de qué y por qué se está realizando el cambio. Si los usuarios van a cambiarlo, se debe crear una interfaz para ocultarlos de los detalles. Lo mismo ocurre a menudo con los no desarrolladores en general.

4. A menudo controlo la fuente de la configuración "predeterminada", pero tengo una manera de anular esto por sistema para el tiempo de ejecución real.

En cuanto a agregar lógica al archivo de configuración, evitaría esto. Creo que es mejor que el archivo de configuración active la lógica en su aplicación. El comportamiento en los archivos de configuración conduce a una falta de capacidad de mantenimiento y comprensión, en mi experiencia. Prefiero mantener los archivos de configuración lo más simple posible.

Tiendo a estar de acuerdo con la premisa de esta pregunta. Evito meterme en problemas al predecir temprano que esto va a suceder y, por lo tanto, nunca utilizo mi propio sistema de configuración.

• O uso la facilidad de configuración del sistema operativo (como plist, gconf o lo que sea apropiado),
• O un simple archivo plano, como puede ser manejado por algo como un analizador INI estándar.
• Muerde la bala y conecte un analizador de lenguaje liviano, generalmente lua, a veces tcl en la aplicación,
• O almacenar datos en una base de datos relacional SQLite o similar.

Y me resigno a vivir con cualquier decisión que tome, o si no puedo, refactorizar para usar una de las opciones anteriores que mejor se adapte a la aplicación.

El punto es que realmente no hay ninguna razón para usar una solución de configuración propia. Por un lado, es más difícil para los usuarios tener que aprender un nuevo formato de configuración específico de la aplicación. Por otro lado, se beneficia de todas las muchas correcciones de errores y actualizaciones que son gratuitas cuando usa una solución lista para usar. Finalmente, Feature creep se pone en reposo, porque, bueno, en realidad no puede simplemente agregar una característica más sin realmente hacer una revisión importante porque el sistema de configuración no está realmente en sus manos en primer lugar.

Depende de lo que acuerde con otros desarrolladores del equipo. ¿Está usando archivos de configuración como archivos de configuración o está creando una aplicación basada en modelos ?

Síntomas de que el archivo de configuración se convierta en un lenguaje de programación:

• los pares nombre = valor comienzan a depender el uno del otro
• siente la necesidad de tener control de flujo (por ejemplo, si (esto) que eso )
• La documentación para el archivo de configuración se vuelve esencial para hacer un mayor desarrollo (en lugar de simplemente usar la aplicación)
• antes de que se lea el valor de la configuración, es necesario tener algo de contexto (es decir, los valores dependen de algo externo al archivo de configuración en sí)

Los archivos de configuración invariablemente avanzan lentamente hasta convertirse en "lenguajes de programación completos" feos e ilógicos. Se necesita arte y habilidad para diseñar buenos lenguajes de programación, y los lenguajes de configuración convertidos en lenguaje de programación tienden a ser horribles.

Un buen enfoque es usar un lenguaje bien diseñado, digamos python o ruby, y usarlo para crear un DSL para su configuración. De esa manera, su lenguaje de configuración puede permanecer simple en la superficie, pero en realidad puede ser el lenguaje de programación completo.

Creo que su pregunta es muy relevante dado el cambio a "interfaces fluidas". Muchos desarrolladores han "visto la luz" con respecto a las aplicaciones configuradas con XML. El uso de XML puede ser muy detallado y difícil de editar correctamente (especialmente si no se proporciona ningún esquema). Tener una interfaz fluida permite al desarrollador configurar la aplicación en un lenguaje específico del dominio con la ayuda de algunos pares clave-valor de un archivo de configuración de texto sin formato (o quizás parámetros de línea de comandos). También facilita la instalación y configuración de nuevas instancias de la aplicación para realizar pruebas o lo que sea.

Aquí están mis respuestas a su pregunta:

• ¿Cuál es el verdadero propósito de un archivo de configuración?

Un archivo de configuración es una forma de permitir al usuario personalizar el comportamiento de su programa en tiempo de ejecución.

• ¿Se debe intentar mantener los archivos de configuración simples?

Idealmente, creo que los archivos de configuración deberían al menos complementarse con una interfaz fluida para configurar el programa (esto es útil en muchos aspectos). Si necesita un archivo de configuración, entonces debe mantenerse muy simple, nada más que pares clave-valor.

• ¿Quién debería ser responsable de realizar cambios en ellos (desarrolladores, usuarios, administradores, etc.)?

Creo que la respuesta a esto depende de su organización. Debería ser responsabilidad de la persona que implementa el software asegurarse de que esté configurado correctamente.

• ¿Deberían ser controlados en fuente (ver pregunta 3)?

Le robaré esta respuesta a alguien más :) Me gusta la idea de almacenar una configuración de plantilla en el control de código fuente y modificarla para las necesidades de cada usuario local. Es probable que el archivo de configuración de un desarrollador sea la pesadilla de otro, por lo que es mejor dejar las cosas que varían según el usuario fuera del control de la fuente. Tener una plantilla también es una buena manera de permitir que la persona que implementa la aplicación (u otros desarrolladores) vea exactamente qué valores son válidos para el archivo de configuración.

He visto programas de Python donde el archivo de configuración es código. Si no necesita hacer nada especial (condicionales, etc.), no se ve muy diferente de otros estilos de configuración. por ejemplo, podría hacer un archivo config.pycon cosas como:

num_threads = 13
hostname = 'myhost'

y la única carga para el usuario, en comparación con (digamos) archivos INI, es que necesitan poner "cadenas". Sin duda, podría hacer lo mismo en otros idiomas interpretados. Le brinda la capacidad ilimitada de complicar su archivo de configuración si es necesario, con el riesgo de asustar a sus usuarios.

Sí, los archivos de configuración deberían ser simples. No deben contener ninguna "lógica" en sí mismos; considérelos como una lista de expresiones en declaraciones if, no como declaraciones condicionales en su totalidad.

Están ahí para permitir que el usuario decida cuál de las opciones codificadas dentro de la aplicación debe usarse, así que no intente complicarlas, terminará siendo contraproducente; puede terminar escribiendo archivos de configuración simples para controlar cómo se debe configurar el archivo de configuración original de lo contrario!

Uno de los propósitos del trabajo "Oslo" en Microsoft es permitir (aunque no exigir) la resolución de este problema.

1. Una aplicación se enviaría con modelos de cualquier componente nuevo que incluya. También utilizaría modelos existentes. Por ejemplo, podría incluir un servicio web, por lo que podría reutilizar el modelo de sistema de un servicio web.
2. Los modelos incluirán metadatos que los describan, incluida suficiente información para que las herramientas puedan acceder a ellos, ya sea textualmente o gráficamente.
3. Partes de los modelos corresponderán a "configuración"

Esto significa que el equivalente de los archivos de configuración actuales puede ser lo suficientemente rico como para admitir la edición tanto textual como gráfica de su configuración. La herramienta gráfica se suministrará con "Oslo" (nombre en clave "Cuadrante").

Seré el contrario y afirmaré que es solo un lenguaje cuando incorpora más de lo que XML puede representar; o bien cuando XML se considera un lenguaje.

Alternativamente, la mayoría de los archivos de configuración se pueden considerar como clases, pero solo con propiedades y sin métodos. Y sin métodos, no creo que sea un idioma.

En última instancia, el "lenguaje" es una abstracción blanda, pero sí, los bordes son ambiguos.

El código de nuestras aplicaciones se vuelve menos importante ... Hay scripting, hay todo tipo de atributos que definen el comportamiento de clases, métodos, argumentos de métodos y propiedades. Los usuarios pueden definir los activadores y las restricciones de la base de datos. Puede haber archivos de configuración muy complicados. A veces, el usuario puede definir hojas de estilo XSLT para manipular la entrada y la salida porque nuestros sistemas deben estar abiertos (SOA). Y hay cosas como BizzTalk que también necesitan una configuración compleja. Los usuarios pueden definir flujos de trabajo complejos.

Tenemos que escribir un mejor código para lidiar con este complejo entorno, por lo que el código de nuestras aplicaciones se vuelve más importante ...

Soy un gran fanático del uso de programas de Python como archivos de configuración, especialmente para demonios. Me gusta tomar la táctica de hacer que el demonio esté completamente vacío de configuración, excepto por el "puerto de configuración". El programa Python luego se conecta al demonio y procede a crear objetos en el demonio y conectarlos para crear la configuración deseada. Una vez que todo está configurado, el demonio se puede dejar para que se ejecute por sí solo. Los beneficios, por supuesto, son que obtienes un lenguaje de programación completo para escribir tus archivos de configuración y dado que ya tienes una forma de hablar con el demonio desde otro programa, puedes usarlo para depurar y obtener estadísticas. La principal desventaja es tener que lidiar con los mensajes de otro programa que llegan en cualquier momento.

Archivo de configuración : "¿Cuál es mi propósito?"
Tú : "Configuras la mantequilla".
Archivo de configuración : "Ok ..."
Archivo de configuración : "¿Cuál es mi propósito?"
Tú : "Tú configuras la mantequilla".
Archivo de configuración : "Oh, Dios mío".

1. No existe un "verdadero propósito" de un archivo de configuración. Es lo que tenga sentido para su aplicación. En general, las cosas que difieren (o pueden diferir) entre máquinas y que no cambian en medio de la ejecución de la aplicación probablemente deberían estar en un archivo de configuración. Los valores predeterminados, los puertos y las direcciones de otros servicios son excelentes candidatos. Las claves y los secretos también son excelentes candidatos, pero deben manejarse por separado de su configuración normal por razones de seguridad. No estoy de acuerdo con que el propósito de un archivo de configuración sea permitir que se realicen cambios rápidos. El propósito debe ser permitir flexibilidad en la configuración de su aplicación. Si un archivo de configuración es un rápido fácil de manera de permitir que la flexibilidad, tanto mejor - pero debería no tener la intención de sus archivos de configuración que se cambian con frecuencia.

2. Si y no. ¿Debería intentar simplificar el código de su aplicación? Si. Debe intentar hacer todo lo que escribe simple y directo. No más complicado de lo que debería ser. Lo mismo ocurre con su configuración. Sin embargo, esto es muy específico de la aplicación. Codificar lo que debería estar en la configuración porque haría que su configuración sea "demasiado complicada" es un mal diseño. De hecho, tratar de "mantener las cosas simples" es la razón por la que los archivos de configuración terminan siendo un desastre gigante. A veces, el movimiento más simple es modularizar. Es por eso que sus archivos de configuración deben estar escritos en un lenguaje de programación de propósito general conocido, no en un lenguaje de configuración terrible (lea: todos los "lenguajes de configuración" apestan ).

3. Nuevamente, quién debería modificar los archivos de configuración depende completamente de la aplicación. Pero estoy de acuerdo con miniquark, quien esté implementando la aplicación debería estar a cargo de la configuración.

4. Controla la fuente todo lo que puedas. El control de fuente es genial. Puede revertir cosas muy fácilmente y tiene un historial completo de los cambios que ha realizado y un registro de quién hizo esos cambios. ¿Entonces por qué no?