¿Qué es un code smell?
Cultura de ingeniería y práctica de software
Un code smell es una señal rápida en el código fuente que puede apuntar a un problema de diseño más profundo. No es un error en sí mismo. El software puede seguir funcionando perfectamente bien. Un smell simplemente sugiere que el código podría ser más difícil de lo necesario de entender, probar, ampliar o modificar con seguridad. Algunos ejemplos son las funciones largas, la lógica duplicada, las clases sobredimensionadas, las listas de parámetros incómodas y las responsabilidades entrelazadas.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Un smell es una advertencia, no un veredicto. Es el momento en que un ingeniero echa un vistazo a un fragmento de código y piensa: esto parece raro, y las cosas raras suelen tener una razón. Quizás el código hace demasiadas cosas. Quizás la misma regla aparece en tres lugares. Quizás un cambio pequeño requiere ediciones en cinco archivos distintos.
Por eso funciona la metáfora. No hace falta un diagnóstico completo para notar que algo no está bien. Los smells son fáciles de detectar. La pregunta de fondo es si el smell es inofensivo o si está apuntando a una deuda técnica que seguirá haciendo el trabajo futuro más lento y arriesgado.
Dentro de esta familia de términos, un smell es el aviso más leve. Es menor que el spaghetti code, mucho menor que una big ball of mud, y a menudo es la primera pista de que el bit rot o la deuda acumulada ha empezado a afectar a una parte del sistema.
Por qué importa
El code smell ofrece a los equipos un lenguaje compartido para hablar de mantenibilidad sin convertir cada revisión en un drama moral. En lugar de decir "este código es malo", un ingeniero puede decir "esto huele a duplicación" o "esto huele a demasiadas responsabilidades". Eso cambia el tono: de la culpa a la investigación.
También importa porque el software rara vez se vuelve difícil de cambiar de golpe. Los problemas llegan primero como pequeñas señales. Una función crece. Se cuela un caso especial. Datos que deberían ir juntos empiezan a viajar por separado. Una clase se convierte poco a poco en el lugar donde va todo. Los smells ayudan a los equipos a detectar esas señales antes de que se normalicen.
Para líderes y no especialistas, el término es útil porque conecta la calidad del código con la fricción práctica. Si un equipo dice repetidamente que un área "huele", generalmente está indicando que los cambios futuros en esa zona serán más costosos de lo necesario.
Cómo funciona
El origen del término
La expresión fue acuñada por Kent Beck mientras trabajaba con Martin Fowler en el libro Refactoring. La idea era deliberadamente modesta. Un smell no es prueba de fracaso. Es una señal superficial que a menudo corresponde a un problema más profundo y merece una mirada más atenta.
Esa modestia es parte de la durabilidad del término. Los ingenieros no necesitan un teorema formal para notar que algo es incómodo. Necesitan una forma de señalar el riesgo con antelación, antes de que un defecto, un incidente o un retraso en el calendario fuercen la situación.
Smell frente a bug
Un bug tiene que ver con el comportamiento. El software hace algo incorrecto. Un smell tiene que ver con el diseño y la capacidad de cambio. El software puede hacer lo correcto hoy, pero la forma del código sugiere que el cambio de mañana será más difícil de lo que debería.
Esa diferencia es importante porque evita que los equipos discutan sobre lo que no corresponde. No se corrige un smell porque sea moralmente desordenado. Se aborda cuando su estructura hace que entender el código sea más lento, las pruebas sean más débiles o los cambios futuros sean más frágiles.
A veces un smell se encuentra en un rincón poco activo del sistema y causa pocos problemas. Otras veces está en la ruta más transitada del producto y amplifica cada nueva solicitud. El contexto importa.
Los tipos de smells que la gente realmente nota
Algunos smells son casi visuales. Una función larga hace que los lectores frunzan el ceño porque les pide que mantengan demasiadas ideas en la cabeza a la vez. Una clase gigante sugiere que algo en el sistema se ha convertido poco a poco en el vertedero de todos.
Algunos smells son estructurales. La lógica duplicada significa que una regla irá divergiendo entre las distintas copias. Un data clump, en el que los mismos datos viajan siempre juntos, sugiere que al código le falta un concepto más claro. Un argumento de tipo bandera puede indicar que una función en realidad está fingiendo ser dos o tres funciones distintas.
Algunos smells son tanto sociales como técnicos. Si solo un ingeniero se siente seguro editando un fragmento de código, eso puede no aparecer en el código fuente en sí, pero generalmente refleja algo sobre la estructura. Los smells son a menudo el primer lugar donde la mantenibilidad se hace visible.
Cómo se usan los smells en la práctica
Los buenos equipos usan los smells como detonadores. Un revisor detecta algo extraño y pregunta qué problema más profundo podría estar ocultándose debajo. A veces la respuesta es obvia y se realiza un pequeño refactor de inmediato. A veces la respuesta es "sí, huele, pero este código es estable y no vale la pena tocarlo hoy". Eso sigue siendo una decisión útil, porque se tomó de forma consciente.
Por eso el refactoring y los smells van de la mano. Un smell por sí solo no cambia nada. Solo es útil si el equipo puede hacer el código más fácil de leer, de probar o de ampliar sin cambiar lo que hace el programa.
Los mejores equipos hacen esto de forma continua. No esperan una "fase de limpieza" ceremonial. Mejoran el código donde ya están trabajando, en pequeños pasos seguros, mientras las pruebas siguen en verde.
Por qué la metáfora es mejor de lo que parece a primera vista
A primera vista, el lenguaje de los smells puede parecer subjetivo. En cierto sentido lo es. Los ingenieros desarrollan criterio. Pero eso no es una debilidad. Refleja el contacto repetido con los tipos de estructuras que tienden a causar problemas más adelante.
La metáfora también evita la falsa certeza. Si un equipo dijera que cada arista irregular es un defecto formal, generaría discusiones inútiles. Llamar a algo un smell deja margen para el juicio. Dice: presta atención aquí. El código puede estar bien. También puede estar siendo silenciosamente costoso.
Eso convierte al code smell en un término puente muy útil. Permite a los ingenieros hablar entre sí sobre el riesgo de diseño local, y ofrece a quienes no son ingenieros una forma clara de entender por qué "funciona ahora" no es lo mismo que "fácil de mantener después".
Ejemplos
Un equipo de checkout nota que las reglas de descuento se calculan en la aplicación web, en la aplicación móvil y en un script de exportación de administración. Nada está roto. Los clientes siguen recibiendo los totales correctos. Pero todo el mundo puede oler la duplicación. El próximo cambio de política casi con certeza pasará por alto una copia o las actualizará de forma inconsistente.
Un generador de informes aparentemente sencillo recibe doce parámetros, varios de los cuales siempre viajan juntos. Los ingenieros nuevos siguen intercambiando su orden u olvidando alguno. El smell no es la lista de parámetros en sí. El smell es que al código probablemente le falta un objeto o concepto más claro para transportar esos datos como una sola unidad.
Una clase de cuenta de usuario empieza con buen criterio, pero va acumulando permisos, preferencias de marketing, reglas de notificación, indicadores de fraude y media docena de métodos auxiliares para partes no relacionadas del producto. Cuando el equipo lo nota, cualquier cambio en "usuario" se ha convertido en una pequeña expedición. El smell estaba ahí mucho antes del primer incidente doloroso.
Malentendidos frecuentes
Un code smell no es automáticamente un bug. El código con smell puede seguir siendo correcto. El problema es el riesgo y el coste que genera cuando el código necesita cambiar.
Un code smell no es una orden de refactorizar de inmediato. Algunos smells se encuentran en zonas tranquilas del sistema y no son urgentes. La pregunta importante es con qué frecuencia cambia esa área y cuánto dificulta ese trabajo el smell.
Un code smell no es simplemente una cuestión subjetiva de estilo. El criterio personal juega un papel, pero muchos smells se correlacionan repetidamente con problemas futuros de mantenimiento, especialmente la duplicación, las funciones sobredimensionadas, las dependencias inestables y las responsabilidades confusas.
Un code smell no significa que el autor original fuera descuidado. Muchos smells surgen a través de la evolución normal del producto. El código útil se amplía, se parchea y se reutiliza. La estructura cambia más lentamente que los requisitos.
Que una herramienta no encuentre smells no significa que el diseño sea saludable. Las comprobaciones automatizadas son útiles, pero no pueden sustituir por completo al juicio experimentado sobre el nombrado, los límites conceptuales y si el código refleja la comprensión actual del problema.
Riesgos y límites
El lenguaje de los smells puede usarse de forma abusiva. A veces los equipos agitan el término para ganar discusiones estéticas o para justificar el pulido de partes del código que en realidad no están ralentizando ningún trabajo importante. Eso es simplemente el gusto personal disfrazado de rigor técnico.
También existe el peligro del exceso de refactoring. El código puede volverse tan abstracto, tan ordenado y tan ceremonioso que leerlo resulte más lento que antes. Una buena respuesta a un smell elimina fricción. No debería sustituir un tipo de incomodidad por otro más de moda.
El límite es sencillo. Si el cambio hace que el trabajo futuro sea más claro o más seguro en una parte del sistema que importa, el smell merece atención. Si no, se anota y se sigue adelante.
Qué hacer a continuación
Conviene animar a los revisores a nombrar el smell y la consecuencia probable. "Esto huele a duplicación" es útil. "No me gusta" no lo es. La discusión mejora cuando las personas explican qué problema futuro están intentando evitar.
Hay que crear espacio para pequeñas reparaciones durante el trabajo habitual. Si los equipos solo son recompensados por el código de funcionalidades visibles, los smells se reconocerán y luego se ignorarán hasta que la factura sea mayor. Un pequeño refactor hoy suele ser la forma de mantenimiento más barata disponible.
Por último, conviene vigilar los smells repetidos en la misma área. Una función incómoda es algo ordinario. La misma familia de smells apareciendo alrededor de un módulo, un límite de equipo o una regla de negocio suele indicar que el diseño necesita una revisión más amplia.
¿Tiene alguna pregunta o sugerencia, o quiere saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Es un code smell lo mismo que la deuda técnica?
No exactamente. Un smell es una señal. La deuda técnica es el coste futuro más amplio. Los smells a menudo apuntan a deuda, pero no son idénticos.
¿Siempre vale la pena corregir los code smells?
No. Vale la pena notarlos. Si merece la pena corregirlos depende de con qué frecuencia cambia esa área y cuánto riesgo genera el smell.
¿Pueden usar el término code smell quienes no son ingenieros?
Sí, si lo usan con ligereza. Generalmente significa que el código puede ser correcto ahora pero incómodo de cambiar con seguridad.
¿Cuál es el code smell más común?
No hay un único ganador, pero los equipos suelen detectar muy pronto las funciones largas, la duplicación, las clases sobredimensionadas y las responsabilidades ambiguas.
¿Las herramientas automatizadas detectan los code smells de forma fiable?
Detectan algunos bien, especialmente los mecánicos. Son más débiles a la hora de juzgar los límites conceptuales, el nombrado, la intención y si el diseño refleja la comprensión actual.
¿Cómo debería responder un equipo cuando el código huele pero las pruebas son débiles?
Primero hay que hacer el cambio más seguro. Añadir o mejorar las pruebas suficientes para generar confianza, y luego refactorizar en pequeños pasos. Limpiar smells sin comprobaciones de seguridad puede crear nuevos bugs.