"Código" limpio, rendimiento horrible (2023)
Las críticas al diseño orientado a objetos del estilo “Clean Code” sostienen que su énfasis en métodos diminutos, jerarquías polimórficas profundas e internals ocultos puede llevar a un mal rendimiento al ir contra las cachés de CPU y añadir indirección. Los comentaristas responden que esos patrones estaban pensados para mejorar la legibilidad y la mantenibilidad, y que los verdaderos cuellos de botella suelen estar en otra parte (por ejemplo, I/O de red, frameworks pesados) y no en el despacho virtual. La idea general es que los “principios” de programación como DRY, las funciones pequeñas y las interfaces solo son útiles cuando se aplican con criterio a dominios y restricciones concretos, en lugar de seguirse como dogma.
Valor y limitaciones de Clean Code
- Muchos ven el libro como un andamiaje útil para desarrolladores en etapas tempranas que necesitan estructura.
- Otros sostienen que enseña prácticas malas o demasiado estrechas (“código OOP limpio” únicamente) y que es activamente perjudicial, incluso para principiantes.
- Queja común: fomenta reglas dogmáticas (funciones diminutas, polimorfismo, rechazo de comentarios) y un tono moralizante que etiqueta la discrepancia como “poco profesional”.
- Algunos mencionan una edición más nueva destinada a corregir malas interpretaciones, pero su calidad se describe como poco clara.
Rendimiento vs. mantenibilidad
- Debate central: las abstracciones “limpias” (especialmente OO y polimorfismo) a menudo perjudican el rendimiento, pero pueden facilitar el mantenimiento y la extensibilidad.
- Varios argumentan que el rendimiento debe guiarse por medición: escribir código simple y luego optimizar los puntos calientes.
- Otros responden que ciertos estilos (polimorfismo de ejecución pesado, capas profundas de abstracción) pueden dejar un sistema lento de forma global, no solo en los puntos calientes.
OOP, polimorfismo y alternativas
- Muchos señalan que el ejemplo clásico usa polimorfismo en tiempo de ejecución y vtables, que se sabe que son más lentos que los datos planos y los switches, especialmente en bucles ajustados.
- Algunos subrayan que los compiladores modernos inlinean bien las funciones pequeñas; el coste principal es el despacho dinámico, no “clean code” en sí.
- Alternativas mencionadas: tipos suma con coincidencias exhaustivas, despacho procedimental (switches o tablas), polimorfismo estático y abstracciones de coste cero en lenguajes más nuevos.
Tamaño y estructura de las funciones
- Hay fuerte desacuerdo sobre las reglas de longitud de las funciones.
- A algunos les gustan las funciones muy pequeñas y de propósito único por claridad; otros encuentran ese estilo fragmentado y más difícil de seguir.
- Las funciones largas pero lineales pueden ser aceptables si hacen “una cosa coherente”; la división artificial puede perjudicar la legibilidad.
Principios vs. dogma
- Varios comentaristas enfatizan que principios como DRY, SRP y “clean code” son herramientas de bajo nivel con compensaciones, no leyes universales.
- La sobreaplicación conduce a acoplamiento muerto, fragmentación, baja cohesión y problemas de rendimiento.
- Tema de consenso: usar criterio; el contexto (complejidad del dominio, necesidades de rendimiento, tamaño del equipo, extensibilidad) debe guiar el diseño.
Críticas al artículo y a los ejemplos
- Algunos creen que la crítica ataca un ejemplo de juguete, sin foco en rendimiento, y por tanto equivale a un hombre de paja.
- Otros responden que el ejemplo provenía del propio libro y demuestra de forma concreta cómo el estilo promovido puede degradar el rendimiento, lo cual es un punto válido aunque la intención original fuera pedagógica.
Quejas más amplias del ecosistema
- Varios comentarios sugieren que, en aplicaciones cotidianas, los peores problemas de rendimiento provienen menos de patrones OO y más de pilas pesadas (por ejemplo, Electron, “tecnología web” en escritorio) y de la latencia de red, no del tamaño de las funciones o del polimorfismo por sí solos.