- Es una conversación sobre diseño de software entre Robert “Uncle Bob” Martin y John Ousterhout, realizada entre septiembre de 2024 y febrero de 2025
- Ambos han escrito libros sobre diseño de software
- Mostraron diferencias de opinión en tres temas principales: longitud de los métodos, comentarios y Test-Driven Development
- El núcleo de la conversación trata sobre cómo reducir la complejidad del código y mejorar la legibilidad, así como la forma adecuada de escribir pruebas
Longitud de los métodos
- Uncle Bob (en adelante, UB) enfatiza la postura de que “las funciones cortas son mejores y, si es posible, deben dividirse aún más”
- Un método debe hacer solo “una cosa (One Thing)”
- Sin embargo, si esto se aplica de forma demasiado extrema, puede llevar a una descomposición excesiva (over-decomposition)
- John señala que los métodos demasiado pequeños pueden, por el contrario, dificultar la comprensión del flujo general
- Si hay muchos métodos “superficiales (shallow)”, surge el problema de tener que revisar todos los métodos relacionados para entender una sola funcionalidad
- Aumenta la interdependencia entre métodos (“entanglement”), lo que hace más pesada la lectura del código
- Ejemplo de
PrimeGenerator
- El código original de UB estaba dividido en unas 8 funciones pequeñas, y como los métodos estaban entrelazados entre sí, era difícil de entender
- La versión de John estaba escrita en un solo método, con suficientes comentarios para poder captar el flujo completo de un vistazo
- UB también reconoció en cierta medida que “había una descomposición excesiva”
- En conclusión, ambos reconocen que descomponer el código es importante, pero la clave está en encontrar un equilibrio entre “dividirlo demasiado” y “dejarlo demasiado grande”
Comentarios
- UB tiene la perspectiva de que los comentarios son un “mal necesario (necessary evil)”
- Considera que los comentarios a menudo no se actualizan bien o corren el riesgo de contener información incorrecta
- Prefiere revelar la intención al máximo a través del propio código y, si hace falta, usar nombres muy largos
- John sostiene que los comentarios son imprescindibles
- Si se deja claramente escrita en inglés la finalidad de la interfaz (método) o la intención de la implementación, se reduce el tiempo que otros desarrolladores pierden revisando código innecesario
- Considera que “lo más peligroso es la situación en la que no hay comentarios y hay que interpretar el código directamente”
- Usando
PrimeGenerator como ejemplo, John señala que sin comentarios que expliquen “por qué el algoritmo funciona de esa manera”, es muy difícil entenderlo
- UB sostiene que “si los comentarios no son precisos, hacen más daño que bien”, pero John se inclina por la idea de que “la ausencia de comentarios es aún más perjudicial que tener comentarios incorrectos”
- Ambos coincidieron hasta cierto punto en que “debe usarse un nivel adecuado de comentarios según el equipo y el contexto”, pero en general John valora mucho más su utilidad
Refactorización de PrimeGenerator por John
- John reorganizó el código, que originalmente estaba dividido en 8 métodos, en un solo método o en una estructura de 2 o 3 métodos
- Agregó comentarios abundantes en las partes necesarias para explicar “por qué se implementa de esta manera”
- Mediante comentarios describió tanto la intención de variables clave como
multiples y primes, como el funcionamiento del algoritmo, para ayudar a comprender el código más rápidamente
- UB señaló que ese código tampoco era completamente intuitivo
- Para explicar un algoritmo complejo seguía haciendo falta tiempo, y el propio autor sintió dificultad durante el proceso de revisión
Refactorización de PrimeGenerator2 por Bob
- Es una versión en la que UB modificó ligeramente el código de John
- Separó algunos métodos adicionales y aplicó una “refactorización posterior”
- En la parte de los bucles mejoró la legibilidad, aunque temporalmente se produjo una caída de rendimiento
- John señaló que “si se divide en métodos demasiado pequeños, pueden surgir problemas de rendimiento”, y UB volvió a hacer cambios para mejorar el rendimiento
- Aun así, debido a la preferencia de UB por “minimizar los comentarios”, John siguió sosteniendo que “sería más fácil de entender si se añadieran más explicaciones”
Test-Driven Development
- UB recomienda activamente el enfoque TDD, en el que primero se escriben pruebas en ciclos cortos y luego se va agregando poco a poco el código necesario para hacer pasar las pruebas fallidas
- Sostiene que con este enfoque el código mantiene siempre cobertura de pruebas y se evita la depuración compleja
- También plantea que el código se refactoriza con frecuencia y se vuelve progresivamente más limpio
- John teme que TDD se desvíe hacia un enfoque demasiado “táctico”
- Señala que “el diseño debería venir primero, pero TDD induce a escribir primero el código —la implementación mínima para la prueba—”
- Considera que un buen diseño requiere pensar de una vez en un alcance más amplio y que es mejor escribir pruebas agrupadas (bundling) para ese código
- UB afirma que puede haber problemas “cuando TDD se aplica mal”, pero que si se practica correctamente ayuda tanto a la cobertura de pruebas como al rediseño (refactorización)
- John expresó la preocupación de que “para principiantes, TDD puede aumentar el riesgo de que el código se vuelva un desastre rápidamente”
- Finalmente, ambos coinciden en que “tanto TDD como el enfoque de bundling pueden producir código excelente si se hacen bien”, aunque difieren en cuál es mejor
Cierre
- John:
- Le preocupa que “Clean Code” enfatice demasiado la división en funciones muy pequeñas y la supresión de comentarios, lo que podría llevar a los lectores a seguirlo de manera extrema
- Si no se añaden suficientes comentarios, el código se vuelve difícil de entender y, como resultado, los desarrolladores terminan invirtiendo más tiempo
- También señala que TDD puede hacer perder de vista el diseño de alto nivel
- UB:
- Explicó que en la segunda edición de “Clean Code” hizo ciertos ajustes e incorporó parcialmente las opiniones de John
- Destacó que, respetando experiencias y perspectivas distintas, al final comparten el objetivo de “apuntar a un código limpio y fácil de mantener”
- En conclusión, ambos ponen como valor principal la importancia del diseño de software y “hacer que el código sea fácil de leer”
- Aun así, existen diferencias de postura en criterios como cómo dividir métodos, cómo usar los comentarios y en qué orden escribir las pruebas
- La clave es encontrar un equilibrio adecuado según el entorno del equipo y la estructura del código, y esforzarse por mejorar continuamente el diseño
14 comentarios
Tengo varios libros de la serie Clean, pero me parece que sirven bien solo como referencia a nivel metacognitivo. Si uno los toma como principios o leyes, se vuelve agotador y tampoco resulta muy práctico. Uncle Bob siempre habla de los principios SOLID, pero personalmente no me parece que haya tanto contenido práctico.
Creo que Code Complete y Clean Code comparten el primer lugar entre los libros más sobrevalorados.
¿Ya salió una traducción de The Philosophy of Software Design? Busqué, pero no pude encontrarla.
Paradójicamente, siento que en lugar de libros del tipo “esto es buen código”, se te queda mucho más grabado un libro irónico como “cómo programar de una forma difícil de mantener”.
Últimamente siento que discutí más por la gente que es fan de cierto stack tecnológico o de cierta arquitectura y habla como si fuera un desastre no adoptar ese stack o esa arquitectura, que por el código limpio. Lo correcto es aplicarlo según la situación; parece que no hay nada que sea bueno en todos los casos.
Qué buen debate.
Ahora que lo pienso, yo también les recomiendo The Philosophy of Software Design de John a los juniors, pero Clean Code no es algo que recomiende particularmente.
Parece que lo importante es no seguir ciegamente solo los titulares, sino entender bien el contexto y aplicarlo.
Los libros de autoformación sobre programación pueden estar bien para principiantes que aún no tienen criterios sobre tecnologías o métodos de implementación, pero creo que su utilidad disminuye a medida que se acumula experiencia. Esto se debe a que no existe una verdad absoluta que encaje en todos los proyectos y entornos, y también hay situaciones en las que los principios generales no se aplican. Como con los consejos de autoayuda en otros ámbitos más generales, parece mejor mantener cierta distancia, aplicar solo lo que sirva según el contexto y no perseguir esos consejos de forma ciega.
Estoy un poco más de acuerdo con lo que dice John.
Creo que la clave es no seguir ciegamente lo que dicen ambos como si fuera un dogma, sino entender por qué lo dicen y avanzar a partir de ahí.
No hay que olvidar que el código limpio no es el objetivo, sino un medio.
Sí, al final lo importante es el equilibrio.
Es útil 👍🏻
Opiniones de Hacker News
Algunas personas pueden ser muy dogmáticas sobre ciertas cosas. No entiendo por qué aceptan estas cosas como si fueran el evangelio
Si experimentas un proyecto que sigue ciegamente las recomendaciones de Uncle Bob, te das cuenta de lo poco valiosas que son
Clean Code es una de las herramientas en la caja de un buen ingeniero de software
Algunas personas simplemente agrupan líneas cercanas y lo llaman "refactorización", en lugar de separar funciones cuando se reutilizan o cuando tiene sentido lógico hacerlo
Hay un caso importante que no se mencionó sobre la importancia de los comentarios
Recomiendo mucho "A Philosophy of Software Design"
Fue una reacción a problemas reales de la industria del software antes del movimiento Clean Code
La opinión de Bob sobre los comentarios es extraña
Los libros de Uncle Bob son algo que uno termina dejando atrás con el tiempo
Tengo una queja sobre el nombre Clean Code