"Convention over configuration" fue durante años la gran bandera de Rails frente a frameworks mucho más explícitos donde tenías que configurar cada pieza a mano. ¿Sigue siendo hoy una ventaja real, o con el tiempo los frameworks "explícitos" (Spring Boot con sus starters, por ejemplo, o el propio ecosistema de Node con sus generadores) han ido copiando lo bueno de las convenciones sin renunciar del todo a la configuración explícita?
Lo que siempre se comenta como contrapartida de las convenciones de Rails es que cuando algo se sale de lo previsto por el framework, acabas peleándote más para entender "qué está pasando por debajo" que si hubieras tenido que escribirlo explícito desde el principio. ¿Es una queja real que os habéis encontrado en proyectos grandes, o exagerada?
Alvaro
Creo que sigue siendo una ventaja real, pero se ha vuelto menos exclusiva de Rails que hace quince años, porque muchos frameworks "explícitos" han ido incorporando buenas convenciones por defecto sin renunciar del todo a la configuración explícita cuando hace falta. Spring Boot con sus starters es el ejemplo que más se cita: sigue siendo Java explícito en el fondo, pero los starters te dan un punto de partida con convenciones razonables muy parecido en espíritu a lo que Rails ofrecía, aunque la filosofía de base sea distinta.
La queja que mencionas (pelearte más para entender qué pasa por debajo cuando algo se sale de lo previsto) es real y la he sufrido, sobre todo con partes más "mágicas" de Rails como Active Record callbacks encadenados o metaprogramación pesada en gemas de terceros. Cuando el comportamiento esperado por convención choca con un caso raro de tu dominio de negocio, entender por qué Rails está haciendo algo que no esperabas puede llevar bastante más tiempo que si hubieras escrito esa parte de forma explícita desde el principio.
Mi conclusión personal: la ventaja de las convenciones es real para el caso común (el 80-90% del desarrollo normal), y el coste aparece justo en ese 10-20% que se sale de lo previsto. Si tu dominio tiene mucha lógica "rara" que no encaja bien con las convenciones estándar de Rails, ese coste puede acabar pesando más que el beneficio inicial.
Jota