La convención sobre 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 repetirse (DRY). [1]
El concepto fue introducido por David Heinemeier Hansson para describir la filosofía del marco web Ruby on Rails , pero está relacionado con ideas anteriores como el concepto de " valores predeterminados sensatos " y el principio del menor asombro en el diseño de la interfaz de usuario .
La frase significa básicamente que un desarrollador solo necesita especificar aspectos no convencionales de la aplicación. Por ejemplo, si hay una clase Ventas en el modelo, la tabla correspondiente en la base de datos se llama "ventas" de manera predeterminada. Solo si uno se desvía de esta convención, como en el caso de la tabla "ventas de productos", es necesario escribir código relacionado con estos nombres.
Cuando la convención implementada por la herramienta coincide con el comportamiento deseado, se comporta como se espera sin necesidad de escribir archivos de configuración. Solo cuando el comportamiento deseado se desvía de la convención implementada se requiere una configuración explícita.
El uso de la frase en Ruby on Rails se centra particularmente en su estructura de directorio y archivo de proyecto predeterminada, que evita que los desarrolladores tengan que escribir archivos de configuración XML para especificar qué módulos debe cargar el marco, lo que era común en muchos marcos anteriores.
Las desventajas del enfoque de convención sobre configuración pueden ocurrir debido a conflictos con otros principios de diseño de software, como el principio de Zen de Python "explícito es mejor que implícito". Un marco de software basado en la convención sobre configuración a menudo implica un lenguaje específico del dominio con un conjunto limitado de construcciones o una inversión de control en la que el desarrollador solo puede afectar el comportamiento utilizando un conjunto limitado de ganchos , los cuales pueden hacer que la implementación de comportamientos que no se expresan fácilmente por las convenciones proporcionadas sea más difícil que cuando se usa una biblioteca de software que no intenta disminuir la cantidad de decisiones que los desarrolladores deben tomar o requiere una inversión de control.
Otros métodos para reducir la cantidad de decisiones que un desarrollador debe tomar incluyen lenguajes de programación y bibliotecas de configuración con una arquitectura multicapa .
Algunos frameworks necesitan varios archivos de configuración, cada uno con muchas configuraciones. Estos proporcionan información específica para cada proyecto, que abarca desde URL hasta asignaciones entre clases y tablas de bases 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 mapeaban las entidades y sus campos a la base de datos describiendo estas relaciones en archivos XML. La mayor parte de esta información podría haberse revelado mediante la asignación convencional de los nombres de clase a las tablas de la base de datos con nombres idénticos 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 el uso de anotaciones de Java (consulte la especificación de JavaBeans, cuyo enlace se encuentra a continuación).
Muchos marcos modernos utilizan un enfoque de convención sobre configuración .
Sin embargo, el concepto es más antiguo, ya que se remonta al concepto de valor predeterminado y se puede encontrar 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]
"Como regla general, no queremos inventar una enorme clase java.beans.everything de la que la gente tenga que heredar. En lugar de eso, nos gustaría que los entornos de ejecución de JavaBeans proporcionen un comportamiento predeterminado para los objetos 'normales', pero que permitan que los objetos anulen una parte determinada del comportamiento predeterminado heredando de alguna interfaz java.beans.something específica".