Convención sobre configuración

La convención sobre la configuración (también conocida como codificación por convención ) es un paradigma de diseño de software utilizado por los marcos de software que intenta disminuir la cantidad de decisiones que un desarrollador que utiliza el marco debe tomar sin perder necesariamente flexibilidad y los principios de "no te repitas" (DRY). ^{[ 1 ]}

El concepto fue introducido por David Heinemeier Hansson para describir la filosofía del framework web Ruby on Rails , pero está relacionado con ideas anteriores como el concepto de " valores predeterminados sensatos " y el principio de mínima sorpresa en el diseño de interfaces de usuario .

La frase significa, en esencia, que un desarrollador solo necesita especificar aspectos no convencionales de la aplicación. Por ejemplo, si existe una clase "Ventas" en el modelo, la tabla correspondiente en la base de datos se llama "ventas" por defecto. Solo si se incumple esta convención, como en el caso de la tabla "ventas de productos", será necesario escribir código para especificar estos nombres.

Cuando la convención implementada por la herramienta coincide con el comportamiento deseado, funciona como se espera sin necesidad de escribir archivos de configuración . Solo cuando el comportamiento deseado difiere de la convención implementada se requiere una configuración explícita.

El uso que hace Ruby on Rails de esta frase se centra especialmente en la estructura predeterminada de archivos y directorios de su proyecto, lo que evita que los desarrolladores tengan que escribir archivos de configuración XML para especificar qué módulos debe cargar el framework, algo que era común en muchos frameworks anteriores.

Las desventajas del enfoque de convención sobre configuración pueden surgir debido a conflictos con otros principios de diseño de software, como el principio zen de Python de que "lo explícito es mejor que lo implícito". Un marco de software basado en convención sobre configuración a menudo implica un lenguaje específico de dominio con un conjunto limitado de construcciones o una inversión de control en la que el desarrollador solo puede afectar el comportamiento mediante un conjunto limitado de ganchos , lo que puede dificultar la implementación de comportamientos que no se expresan fácilmente mediante las convenciones proporcionadas, en comparación con el uso de una biblioteca de software que no intenta disminuir la cantidad de decisiones que los desarrolladores deben tomar o que requiere inversión de control.

Otros métodos para disminuir la cantidad de decisiones que un desarrollador necesita tomar incluyen modismos de programación y bibliotecas de configuración con una arquitectura de múltiples capas .

Algunos frameworks requieren varios archivos de configuración , cada uno con numerosos ajustes. Estos proporcionan información específica para cada proyecto, desde URL hasta asignaciones entre clases y tablas de la base de datos. Muchos archivos de configuración con muchos parámetros suelen ser difíciles de mantener.

Por ejemplo, las primeras versiones del mapeador de persistencia de Java, Hibernate, asignaban entidades y sus campos a la base de datos describiendo estas relaciones en archivos XML. La mayor parte de esta información se podía obtener asignando convencionalmente los nombres de las clases a las tablas de la base de datos con el mismo nombre y los campos a sus columnas, respectivamente. Las versiones posteriores eliminaron el archivo de configuración XML y, en su lugar, emplearon estas mismas convenciones, cuyas desviaciones se pueden indicar mediante anotaciones de Java (véase la especificación JavaBeans, cuyo enlace se encuentra más abajo).

Muchos marcos de trabajo modernos utilizan un enfoque de convención sobre configuración .

El concepto es más antiguo, sin embargo, se remonta al concepto de un valor predeterminado , y se puede observar más recientemente en las raíces de las bibliotecas de Java . Por ejemplo, la especificación JavaBeans se basa en gran medida en él. Para citar la especificación JavaBeans 1.01: ^{[ 2 ]}

"Por regla general, no queremos inventar una enorme clase java.beans.everything de la que la gente tenga que heredar. En cambio, nos gustaría que los entornos de ejecución de JavaBeans proporcionaran un comportamiento predeterminado para los objetos 'normales', pero que permitieran a los objetos anular una parte determinada de ese comportamiento predeterminado heredando de alguna interfaz java.beans.something específica."

• Comparación de frameworks web
• Convención sobre código
• Efecto predeterminado
• Principio KISS
• Marcado
• Desarrollo rápido de aplicaciones

• Bachle, Michael; Kirchberg, Paul (2007). "Rubí sobre rieles". Software IEEE . 24 (6): 105– 108. doi : 10.1109/MS.2007.176 . S2CID 9731264 . 
• Miller, Jeremy (febrero de 2009). "Diseño para la convención sobre la configuración" . Revista MSDN . Vol.  24, n.º  2. Consultado el 9 de marzo de 2022 .
• Chen, Nicholas (29 de noviembre de 2006). "Convención sobre configuración" . Archivado del original el 25 de agosto de 2021.

• Convención sobre configuración en Wayback Machine (archivado el 25/08/2021)