Limpia obsesión
Hay días que uno se levanta con ganas de dinamitar algo.
¿Recuerdas la gasolina con plomo y los clorofluorocarbonos (los famosos CFC)? Ambos fueron aclamados en su momento como avances revolucionarios, pero con el tiempo demostraron ser desastrosos para la salud humana y el medio ambiente. Escuece especialmente el caso de la gasolina con plomo, cuya toxicidad era conocida desde hacía décadas. Su inventor, Thomas Midgley -bienintencionado él- nunca cuestionó el impacto a largo plazo de sus ideas. Tampoco lo hicieron los fabricantes de motores y otros productos hasta que hubo que forzar limitaciones a su uso.
Un caso más reciente. El del Dr. Alain Ducan en Francia, que fue expulsado del colegio de médicos por promover prácticas sin base científica que ponían en riesgo la vida de los pacientes. La medicina, al ser una disciplina madura y estrictamente regulada, no permite que individuos sin un respaldo empírico sólido dicten cómo deben trabajar los profesionales de la salud. Sin embargo, muchas personas abrazaron el "Método Ducan" ciegamente como una forma rápida de perder peso.
Ambos casos demuestran cómo la ausencia de pensamiento crítico ante ciertas ideas puede llevar al desastre. En software, aunque afortunadamente las consecuencias nunca son tan dramáticas como en los ejemplos anteriores, la aceptación acrítica de ciertos dogmas ha causado (causa) estragos en la productividad y mantenibilidad del código en demasiados proyectos.
Pertenecemos a una industria donde cualquiera con una idea medianamente bien redactada y arrestos para maquetar un libro puede convertirse en un gurú. No importa si su propuesta no procede de la experiencia real; basta con escribir un libro llamativo y crear un buen discurso de venta. Esto ha sucedido con la filosofía de Clean Code, el Diseño Dirigido por el Dominio (DDD) y la Arquitectura Hexagonal, entre otras corrientes. Más que filosofías útiles a tener en cuenta ante ciertas circunstancias, se han convertido para muchos en dogmas incuestionables.
Antes de que sigas leyendo, matizo: el punto aquí es ilustrar la falta de criterio al aplicar ideas. No estoy comparando tu precioso código limpio y desacoplado con envenenar el planeta o matar a un gordo con inseguridades.
Abrazar dogmas
Queramos o no, el lenguaje tiene un peso. Mucho peso. Algunos creen que el hecho de bautizar como "limpio" cualquier código parido por cierta forma de trabajar se materializará en esa realidad. Por contrapartida lógica, cualquier código que no se genere de esta forma debe ser "sucio". Lo que no entienden es que, del mismo modo que llamar "inodoro" al sanitario conectado a un conjunto de tuberías por donde discurre la mierda no cambia su naturaleza (ni su olor), etiquetar una metodología como "limpia" no la hace intrínsecamente superior.
La filosofía de Clean Code, popularizada por Robert C. Martin, ha sido interpretada como un conjunto de reglas absolutas en lugar de lo que realmente es: un conjunto de sugerencias que pueden, o no, aplicarse dependiendo del contexto. En muchos entornos, Clean Code ha pasado de ser un mero conjunto de buenas prácticas a convertirse en un dogma aplicado sin cuestionamiento para obtener código "limpio" (según su definición, por supuesto) a cualquier costo. Aunque eso signifique una maraña de clases, abstracciones inútiles y capas innecesarias que no aportan valor real más allá que placer para el practitioner entregado.
Algo similar ocurre con la Arquitectura Hexagonal y el DDD. Estos enfoques son muy útiles en ciertos contextos, pero se han impuesto como verdades universales. Se aplican incluso en proyectos minúsculos donde una simple arquitectura en capas o un enfoque pragmático serían más eficientes. El resultado: código ilegible, sobreingeniería y una curva de aprendizaje artificialmente empinada para cualquier nuevo desarrollador que se una al equipo.
Trivia
¿Sabías que el tal Bob Martin ha dedicado prácticamente la totalidad de su vida profesional a "idear y evangelizar" y que no se le conocen proyectos de calado ni código, más allá del que ha escrito para ilustrar sus propuestas? ¡Ah! también ha incluído la palabra "clean" en los títulos de todos sus libros escritos desde 2009 (un total de 5). Algo similar ocurre con Alistair Cockburn (otro teórico) y su Arquitectura Hexagonal. Sin embargo, DDD sí que parece venir de alguien con experiencia demostrable (Eric Evans).
Aunque he buscado activamente durante un tiempo consierable y no he encotado nada, puedo tener información incorrecta. Estaría encantado de que alguien me apuntase cualquier recurso que me haga salir de mi error.
¿Por qué lo hacemos?
El problema no es solo la proliferación de estos dogmas, sino que existen ejemplos claros de cómo el pragmatismo ha llevado a soluciones superiores en mantenibilidad e impacto.
Proyectos como Ruby on Rails, SQLite, Redis, Linux y Go, entre otros, han demostrado que la simplicidad y la eficiencia pueden llegar muy lejos, sin recurrir a arquitecturas complejas. Curiosamente, son la base sobre la que se sustentan muchos de los sistemas que siguen los principios de Clean Code y Arquitectura Hexagonal.
¿Por qué, entonces, no son considerados ejemplos a seguir por quienes promueven estas metodologías? Si sus principios fueran realmente infalibles, ¿no sería lógico que los sistemas más exitosos los aplicaran desde su concepción? ¿No debería haber llegado el sector de manera natural a estas conclusiones tras la ingente cantidad de horas/hombre invertidas en desarrollo de software?
Y sin embargo, los proyectos y los profesionales que sostienen Internet han priorizado siempre la eficiencia y sencillez sobre la sobreingeniería. Si las grandes infraestructuras tecnológicas dependen de soluciones pragmáticas, ¿qué sentido tiene imponer arquitecturas sobrecomplicadas en proyectos claramente menores?
La respuesta es simple: la industria abraza modas y ensalza textos escritos por personas que rara vez han construido software real, con impacto real y a una escala real. En esta industria, un autor con buen marketing tiene más influencia que un ingeniero con experiencia real en producción. Y la única diferencia en muchos casos es que uno ha escrito un libro y otro no.
Peor aún, estas metodologías no solo se aplican erróneamente en muchos casos. Se enseñan como dogmas incuestionables, perpetuando este problema. En lugar de formar ingenieros con criterio y capaces de tener una opinión formada a base de años de experiencia, se les instruye para seguir reglas sin cuestionarlas. Porque, ¿quién no va a querer escribir "código limpio"? ¿quién va a ser el gili que trabaje con una arquitectura sucia y, oh Dios, acoplada?
Cuando estos ingenieros llegan al mundo real, replican estos patrones sin evaluar si son adecuados para el contexto en el que trabajan. En otras disciplinas técnicas, los errores metodológicos se corrigen con formación rigurosa y, por qué no, regulación. En software, esta corrección estructural no es posible, lo que permite que la sobreingeniería y la ineficiencia se propaguen sin control.
En nuestro caso, la comunidad debería tener, en conjunto, la madurez suficiente para rechazar a los charlatanes de forma natural: confrontando sus discursos, dejando atrás las modas sin fundamento y valorando la experiencia real sobre las frases llamativas. En lugar de ensalzar a quienes venden teorías atractivas sin sustento práctico, deberíamos escuchar a quienes han construido software funcional y han aprendido de los problemas reales del día a día.
Pragmatismo por encima de dogma
Los libros están para leerlos, analizarlos y extraer de ellos las mejores enseñanzas, si es que las tienen. Los problemas a los que se enfrentan los programadores son los mismos desde los inicios de la informática. Si existiera una forma mecánica de tener un código ideal, el problema se habría resuelto hace más de 40 años: existiría un manual, no una lista interminable de superventas.
Avanzar en la profesión requiere aprender a valorar la experiencia sobre la retórica, la utilidad sobre la estética y el pragmatismo sobre la adhesión ciega a metodologías, porque el software no necesita reglas inamovibles. Los principios cualquier metodología deben ser herramientas, no mandamientos. El código "limpio" nunca va a existir, pero sí el código con abstracciones y semántica adecuadas; y eso no implica sobreingeniería, sino equilibrio y sentido común.
En mi opinión, ser pragmático no es rechazar ni abrazar metodologías. Es aplicarlas cuando realmente aportan valor.