Adiós, código limpio (2020)
Los esfuerzos por aplicar rigurosamente principios de “código limpio” como DRY y la abstracción agresiva pueden salir mal, argumentan muchos ingenieros, cuando reducen la flexibilidad y hacen que los cambios futuros sean más difíciles en lugar de más fáciles. Los comentaristas contrastan el código duplicado pero directo y específico del dominio con versiones abstraídas que enredan casos no relacionados, aumentan la carga cognitiva y a menudo reflejan intentos prematuros de generalizar a partir de muy pocos ejemplos. Un tema recurrente es que la mantenibilidad depende tanto del buen juicio, la comunicación y las concesiones conscientes del contexto como de cualquier regla de estilo o dogma de diseño específico.
Código limpio, DRY y abstracción
- Muchos argumentan que el refactor fracasó porque creó una mala abstracción, no porque el “código limpio” sea inherentemente malo.
- DRY se ve como una pauta: es valioso cuando varios lugares siempre deben cambiar juntos; perjudicial cuando fuerza casos no relacionados a entrar en una sola ruta.
- Varios comentarios enfatizan “abstrae de abajo hacia arriba, no de arriba hacia abajo”: primero deja que se acumulen casos de uso concretos y luego extrae ayudas simples y obvias.
- Una heurística recurrente: la duplicación de conocimiento o comportamiento merece abstracción; la similitud superficial en la forma del código a menudo no.
Cuando la duplicación es preferible
- Varios participantes dicen que “la duplicación es más barata que la abstracción equivocada”. Las abstracciones erróneas se vuelven frágiles, añaden condicionales y casos especiales, y son difíciles de deshacer.
- Para dominios en evolución (gráficos, productos financieros, lógica de negocio compleja), mantener rutas de código separadas pero similares a menudo preserva la flexibilidad para futuras divergencias.
- Algunos señalan que editar la misma lógica en unos pocos lugares rara vez es el verdadero factor de costo; depurar una abstracción enmarañada sí lo es.
Evaluando el canon de “Código limpio”
- Algunos critican el estilo de “Clean Code” por dogmático, con pocas advertencias, y atractivo para juniors que aplican reglas mecánicamente (p. ej., “muchas funciones diminutas”, DRY a cualquier costo).
- Otros señalan que los textos originales presentan las recomendaciones como controvertidas y no autoritativas, e insisten en que el mal uso es un error del lector, no del libro.
- Existe preocupación de que los linters y los equipos hayan convertido pautas flexibles en doctrina rígida.
Dinámica de equipo y proceso
- Muchos ven el error principal como social/de proceso: reescribir de noche el trabajo reciente de un compañero y hacer commit sin discusión ni revisión.
- Las opiniones se dividen entre “el código pertenece al equipo; cualquiera puede refactorizar” y “el contexto y la etiqueta importan; las reescrituras unilaterales dañan la confianza”.
- Alternativas sugeridas: comentarios de revisión, extracción incremental de helpers, PR separados con el autor original incluido.
Perspectivas sobre lenguaje y paradigma
- Algunos elogian los lenguajes funcionales (p. ej., con leyes de Applicative/Monad) por abstracciones estandarizadas y reutilizables, reduciendo las específicas del proyecto.
- Otros destacan el tradeoff opuesto de Go: menos abstracciones a nivel de lenguaje, más duplicación, pero un modelo mental más simple.
- Hay debate sobre jerarquías orientadas a objetos para geometría (p. ej., cuadrados frente a rectángulos) y cómo la mutabilidad rompe abstracciones ingenuas.
Pruebas, mantenibilidad y practicidad
- Un sector argumenta que pruebas intensivas habrían permitido una “refactorización sin miedo” y habrían hecho el cambio incuestionable.
- Otros responden que las pruebas no resuelven la complejidad cognitiva ni los problemas sociales; un código estéticamente o estructuralmente malo puede estar completamente probado y aun así ser perjudicial.
- Hay amplio acuerdo: la mantenibilidad, la claridad de la lógica de negocio y la facilidad de cambio prevalecen sobre la estética o la reducción del número de líneas.