Clean Code en Proyectos Reales: Qué Aplicar, Qué Adaptar y Qué Ignorar

Hay un momento que todo equipo reconoce: alguien abre un fichero de hace dos años, mira una función de 400 líneas llamada processData y dice «esto hay que rehacerlo». Alguien más responde: «no lo toques, funciona». Los dos tienen razón, y en esa tensión vive Clean Code.

Desde que Robert C. Martin publicó el libro en 2008, «código limpio» se ha convertido a la vez en estándar de facto y en religión. Y como toda religión, tiene devotos que aplican cada regla al pie de la letra y herejes que lo ignoran todo. Esta guía va del término medio rentable: qué reglas pagan siempre, cuáles dependen del contexto y cuáles puedes ignorar sin que se te caiga la cara de vergüenza en la próxima retro.

Qué es Clean Code de Verdad (y Qué No)

Clean Code no es un estilo ni una estética: es una decisión económica. El código se lee decenas de veces más de lo que se escribe — lo lees tú dentro de seis meses, lo lee el compañero que hereda tu módulo, lo lee quien depura una incidencia a las tres de la mañana. Escribir código limpio es pagar un pequeño sobrecoste hoy para abaratar todas esas lecturas futuras.

Y no es:

• Una lista de reglas sagradas. El propio Martin presenta las suyas como heurísticas aprendidas de la experiencia, no como mandamientos. Tratarlas como dogma produce código «limpio» que nadie puede mantener.
• Sinónimo de perfecto. El código limpio es el que comunica su intención y admite el siguiente cambio sin dolor. Nada más. Perseguir la perfección es procrastinar con buena conciencia.
• Un sustituto del diseño. Puedes tener funciones de cinco líneas impecables sobre una arquitectura podrida. La limpieza opera en lo pequeño; la estructura la dan decisiones como los puertos y adaptadores de la arquitectura hexagonal.

Las Reglas que Rentan Siempre

Hay un núcleo de prácticas cuyo retorno no depende del contexto: cuestan poco y pagan siempre. Si solo te quedas con una sección de este artículo, que sea esta:

• Nombres que dicen la verdad. calcularPrecioConDescuentoFidelidad en vez de calc. El nombre es la documentación que no se queda desactualizada. Si no encuentras un nombre bueno, probablemente la función hace dos cosas.
• Funciones pequeñas con una sola responsabilidad. No por estética: porque una función que hace una cosa se puede testear, nombrar y reutilizar. Una que hace cinco solo se puede temer.
• El código muerto se borra. El código comentado, los métodos «por si acaso» y las ramas que nunca se ejecutan no son prudencia: son ruido que alguien tendrá que leer. Para eso está git.
• Los tests son parte del código. Un cambio sin tests es un préstamo que paga el siguiente. La pirámide de testing te dice cuántos y de qué tipo; lo innegociable es que existan.
• Deja el código mejor de lo que lo encontraste. La regla del boy scout: cada vez que tocas un fichero, mejora algo pequeño. Es la estrategia más barata contra la deuda técnica porque reparte el pago en el día a día en vez de acumularlo para un proyecto de rescate que nunca llega.

Las que Hay que Adaptar al Contexto

La segunda categoría es donde se gana o se pierde el juicio de ingeniero: reglas valiosas que aplicadas a martillazos se vuelven en tu contra.

• DRY (Don't Repeat Yourself). Eliminar duplicación es sano; eliminarla antes de tiempo crea acoplamiento entre cosas que solo coincidían por casualidad. La heurística práctica: la primera copia se tolera, la segunda se mira con sospecha, la tercera se refactoriza. Duplicar es barato; desacoplar una abstracción prematura es carísimo.
• SOLID. Cinco principios pensados para código que cambia mucho. Aplicados donde el cambio ocurre de verdad, son oro; aplicados preventivamente a todo el codebase, producen interfaces con una sola implementación y factorías de factorías. SOLID no es un destino: es una respuesta al dolor.
• Comentarios. «El buen código se documenta solo» es verdad a medias. El qué se documenta solo si los nombres son buenos; el porqué — por qué se eligió esta aproximación, qué se intentó antes y falló — no cabe en un nombre. Comenta el porqué, nunca el qué.
• Cobertura de tests. El 100% de cobertura no garantiza nada (puedes ejecutar cada línea sin afirmar nada sobre el resultado) y perseguirlo convierte los tests en una carga. Cubre las reglas de negocio y los caminos que rompen cosas; el getter del DTO te lo perdonamos.

Lo que Puedes Ignorar Sin Culpa

Y luego está la parafernalia: prácticas que suenan profesionales pero que en la mayoría de proyectos restan más de lo que suman.

• Abstracciones especulativas. «Algún día tendremos otro proveedor de pagos, hagamos una interfaz». Quizá. Pero hasta que llegue el segundo caso real, la interfaz es un impuesto a la lectura sin ningún retorno. YAGNI no es pereza: es respeto por el futuro lector.
• Patrones por catálogo. Si tu código necesita un diagrama de clases para explicarse, no es sofisticado: es barroco. Un patrón es una respuesta a un problema concreto; sin el problema, es decoración.
• La guerra de formatos. Tabs contra espacios, llaves aquí o allá: es lo que menos impacto tiene en la mantenibilidad y donde más energía se quema. Configura un formatter automático, súbelo al CI y no vuelvas a hablar del tema.
• Refactors sin propósito. Reescribir un módulo «porque es feo» sin que duela en ninguna métrica es vanidad, no ingeniería. La limpieza se justifica con cambios futuros más baratos; si nadie va a tocar ese código, su fealdad es gratis.

El Argumento Económico

La gráfica clásica del libro sigue siendo la mejor justificación: sin disciplina, el coste de cada cambio crece con la edad del código hasta que el equipo pasa más tiempo esquivando el sistema que mejorándolo. Con código limpio, el coste se mantiene plano. El punto de cruce llega antes de lo que parece: en un proyecto con vida de años, la disciplina se paga sola en meses.

La conclusión práctica para hablar con negocio: Clean Code no es una preferencia de los desarrolladores, es la diferencia entre «podemos cambiar esto la semana que viene» y «eso es imposible sin reescribir medio sistema». Cuando alguien cuestione el tiempo invertido en limpieza, la pregunta correcta no es cuánto cuesta limpiar, sino cuánto cuesta no poder cambiar.

Errores Comunes al Adoptarlo

1. Adoptarlo de golpe. Decidir el lunes que «desde hoy todo será clean» produce fricción, PRs imposibles de revisar y abandono en tres semanas. Se adopta por hábitos pequeños: nombres primero, funciones pequeñas después, lo demás con el tiempo.
2. Convertirlo en arma de code review. Si las revisiones se convierten en caza de herejes, el equipo aprende a temer el feedback, no a escribir mejor. La regla del boy scout aplica también a las personas: educa con el ejemplo, no con el escarnio.
3. Limpiar lo que no duele. Invertir dos días en un script que se ejecuta una vez al año es un lujo que el proyecto no te agradece. La limpieza sigue al cambio: limpia lo que tocas, no lo que te molesta ver de lejos.
4. Confundir limpio con corto. Una función de dos líneas que esconde efectos colaterales es peor que una de veinte que se lee de corrido. La métrica no es la longitud: es el tiempo que tarda un desconocido en entender qué hace.
5. Limpiar sin tests debajo. Refactorizar código sin cobertura es trapecio sin red. Si el módulo es feo y no tiene tests, el primer acto de limpieza es escribir los tests que caracterizan su comportamiento actual — después ya tocas.

En Resumen

Clean Code es una decisión económica: el código se lee mucho más de lo que se escribe, y la limpieza abarata cada lectura futura. Rentan siempre los nombres honestos, las funciones pequeñas, los tests y la regla del boy scout. Hay que adaptar al contexto DRY, SOLID, los comentarios y la cobertura. Y se puede ignorar sin drama la abstracción especulativa, los patrones por catálogo y las guerras de formato. El objetivo no es código bonito: es un sistema que siga siendo cambiable dentro de dos años.

Si tu equipo discute más sobre estilo que sobre negocio, o si cada cambio cuesta más de lo que debería, una auditoría de código pone números y plan encima de la mesa. Cuéntanos tu caso →

Sigue leyendo: Deuda técnica: qué es de verdad, cuándo es buena y cómo se paga.