Contexto y quién habla
Dave Thomas es una figura legendaria en la comunidad Ruby: coautor de The Pragmatic Programmer, uno de los firmantes iniciales del Manifiesto Ágil, y autor de varios libros influyentes sobre Ruby y desarrollo de software. Su experiencia de décadas hace que lo que propone esté menos en plan “dogma” y más como una invitación a replantear nuestras suposiciones. (RubyEvents.org)
La tesis central: recalibrar cómo estructuramos código en Ruby
Thomas parte de una observación crítica: “Estamos escribiendo nuestro código Ruby de forma equivocada”. Esa frase es más que provocadora: es una invitación a desafiar un hábito que se ha vuelto casi automático. (sfruby.com)
Su propuesta principal es:
Dejar de usar clases como la unidad fundamental de diseño en Ruby cuando no es necesario.
Esto no significa abolir clases—sino reconsiderar su papel —especialmente cuando alternativas más simples pueden hacer el código más claro, mantenible y flexibles a cambios futuros. (sfruby.com)
¿Por qué parar con clases?
Ruby es un lenguaje extremadamente expresivo y flexible: las clases son solo una de muchas herramientas para estructurar código. Dave Thomas argumenta que:
- Hemos desarrollado una “dependencia mental” en clases por tradición más que por necesidad real.
- Diseñar todo alrededor de clases a menudo nos lleva a patrones complejos (“design patterns”) que en muchos casos son artefactos culturales de lenguajes más rígidos (como Java o C++), no de Ruby. (sfruby.com)
En otras palabras: las clases no son la unidad más natural de pensamiento en Ruby.
Un enfoque alternativo: estructura desde el crecimiento real
Cuando diseñamos software tradicionalmente:
- Pensamos en la estructura primero.
- Escribimos clases y jerarquías.
- Luego codificamos.
Thomas propone algo más parecido a trabajar desde exploración y crecimiento orgánico:
- Comienza con pequeñas funciones, módulos y bloques que reflejen exactamente lo que necesitas ahora.
- Permite que la estructura emerja conforme el problema y su complejidad crecen.
- Solo introduce clases o abstracciones más grandes si se vuelve claro que aportan valor. (sfruby.com)
Esto es similar al enfoque evolutivo propio del desarrollo ágil, aplicado a la forma de escribir código mismo.
Ventajas de este enfoque
Dave Thomas señala beneficios prácticos:
Simplicidad
Menos artefactos ceremoniales (clases complejas, jerarquías rígidas) significan menos sobrecarga mental, menos convenciones que memorizar, y código que “dice lo que hace”. (sfruby.com)
Mantenibilidad real
Cuando la lógica está en funciones o módulos centrados en acciones claras, es más fácil modificar y razonar sobre ellos. Esto encaja con la filosofía de mantener el código flexible y adaptativo (un principio clave del desarrollo ágil). (sfruby.com)
Menos dependencias innecesarias
Menos clases puede significar menos dependencias entre partes del sistema, lo que hace más fácil reusar, testear y reemplazar componentes. (sfruby.com)
¿Qué pasa con patrones clásicos de diseño y metodologías?
Otra parte de la charla—y probablemente la más filosófica—es que muchos de los patrones de diseño que aprendemos y aplicamos vienen del mundo de lenguajes más estáticos. En Ruby, muchas veces:
- Objetos no son lo que pensamos.
- Clases no siempre son la forma más natural de expresar una abstracción.
- DSLs (Domain Specific Languages), bloques y módulos pueden hacer el trabajo de formas más expresivas. (sfruby.com)
Esto no implica abandonar conceptos, sino reapropiarlos de forma más idiomática para Ruby.
Ejemplos implícitos en la charla
Aunque la charla en sí usa ejemplos concretos (código en vivo), el patrón general que Thomas muestra es:
- Escribir funciones pequeñas y enfocadas.
- Encapsular comportamiento relevante en módulos en vez de clases generales.
- Evitar jerarquías profundas y rígidas que enmascaran la intención real del código. (sfruby.com)
Este estilo se alinea con prácticas contemporáneas que favorecen la composición y la inmutabilidad funcional cuando tiene sentido.
Un empujón hacia pragmatismo
Este mensaje no tiene truco: no dice “deja de usar clases por decreto”, sino:
Piensa críticamente sobre cuando realmente aportan valor y cuando simplemente seguimos patrones por costumbre.
Ruby es un lenguaje expresivo; abrazar ese poder puede permitir código más simple y sostenible con menos artefactos sintácticos. (sfruby.com)
Deja una respuesta