Si llevas un par de años programando en serio, ya conociste a Uncle Bob aunque no sepas que se llama así. Lo conociste cuando alguien te mandó a “hacer las funciones más chicas”. Cuando un revisor te puso “esto viola SRP”. Cuando te recomendaron Clean Code en tu primera semana. O cuando viste a un compañero refactorizar tres horas para que un módulo “respete Open/Closed”, y al final no entendiste si quedó mejor o peor.
Robert C. Martin —Uncle Bob para todos— es probablemente la persona viva con más impacto en cómo se enseña a escribir código en empresa. Tiene 73 años, lleva programando desde 1970 (más de medio siglo), firmó el Manifiesto Agile en Snowbird, fundó Object Mentor, y escribió siete u ocho libros que se citan en cada code review.
También es polémico. Algunas de sus reglas son sólidas como el granito y otras se desmoronan en cuanto les tocas un microbenchmark. Este post va de cuáles son cuáles, con sus libros, sus citas verbatim, y los matices que ya nadie debería ignorar en 2026.
Quién es y por qué importa
Robert Cecil Martin nació el 5 de diciembre de 1952 en Estados Unidos. Empezó a programar a los 17 años en una IBM 360 escribiendo COBOL y Fortran. En 1991 fundó Object Mentor, una consultora que le pagaba a él y a su hijo Micah por enseñar diseño orientado a objetos en empresas grandes — eso lo puso, durante 15 años, dentro del código de bancos, aseguradoras y manufactureras viendo cómo de verdad se construye software a escala.
En febrero de 2001, fue uno de los 17 firmantes del Manifiesto Agile en Snowbird, Utah. Y desde 2002 dedicó la mitad de su carrera a un proyecto editorial muy específico: escribir los libros que él hubiera querido leer cuando empezó. Esos libros son la razón por la que sigue importando.
Sus libros, en el orden que vale la pena leerlos
No son ocho libros sobre lo mismo. Cada uno responde a una pregunta distinta. Aquí está el orden recomendado:
| # | Año | Libro | Pregunta que responde |
|---|---|---|---|
| 1 | 2008 | Clean Code (Prentice Hall) | ¿Cómo escribo funciones, clases y archivos que otro humano pueda leer? |
| 2 | 2011 | The Clean Coder (Prentice Hall) | ¿Cómo me comporto profesionalmente como ingeniero? |
| 3 | 2002 | Agile Software Development: Principles, Patterns, and Practices (PPP, Prentice Hall) | ¿Cuáles son los principios de diseño OO en los que se basa todo lo demás? |
| 4 | 2017 | Clean Architecture (Pearson) | ¿Cómo organizo un sistema completo para que envejezca bien? |
| 5 | 2019 | Clean Agile: Back to Basics (Pearson) | ¿En qué se convirtió Agile y cómo regresamos a la idea original? |
| 6 | 2021 | Clean Craftsmanship (Pearson) | ¿Qué disciplinas mínimas debe tener un programador profesional? |
| 7 | 2023 | Functional Design (Pearson) | ¿Y todo esto cómo se hace en lenguajes funcionales? |
El más famoso —por mucho— es Clean Code de 2008. Es el que aparece en el escritorio de cada arquitecto que conoces. Es bueno, pero ya no es el mejor lugar para empezar: muchos de sus consejos puntuales están en discusión. El que mejor envejeció es Clean Architecture (2017): es el más independiente del lenguaje, el más portable a equipos modernos, y el menos polémico.
Si vas a leer uno solo, lee Clean Architecture. Si vas a leer dos, agrega Agile Software Development: PPP (2002) — paradójicamente el más antiguo y todavía el más rico en principios.
SOLID — el corazón de su obra
Si Uncle Bob deja sólo una herencia conceptual, son los principios SOLID. Y aquí hay una historia chiquita que casi nadie cuenta: el acrónimo no es de él. Bob enumeró los principios en distintos artículos a lo largo de los 90s y los formalizó en su libro de 2002, pero fue Michael Feathers —autor del clásico Working Effectively with Legacy Code (2004)— quien acomodó las iniciales en orden y formó SOLID. Bob lo adoptó después y se quedó como el padre del set, con razón: él es quien los escribió.
Aquí van, en plain language, cada uno con un ejemplo software-real.
S — Single Responsibility Principle (SRP)
“A class should have only one reason to change.”
(Una clase debería tener una sola razón para cambiar.)
— Robert C. Martin, Agile Software Development: PPP (2002)
La traducción más útil: una clase tiene una audiencia. Un reporte de ventas tiene como audiencia al área comercial. Un exportador a PDF tiene como audiencia al equipo de operaciones. No metas las dos cosas en la misma clase. Cuando comercial pida cambiar el reporte, no quieres tocar el exportador y posiblemente romper PDFs que ya estaban bien.
Cómo se viola en la vida real: la clase User que tiene método save(), sendEmail(), validateAddress(), generateInvoicePdf(). Cuatro audiencias distintas dentro de la misma clase. Cuando el equipo de billing cambie el formato del PDF, vas a tocar la misma clase que usa autenticación. Mal asunto.
Matiz importante: SRP no es “una clase, una función”. Es una razón para cambiar. Una clase con 8 métodos cohesivos puede respetar SRP perfectamente. Una clase con 2 métodos que sirven a dos áreas distintas, ya la viola.
O — Open/Closed Principle (OCP)
“Software entities should be open for extension but closed for modification.”
(Las entidades de software deberían estar abiertas a la extensión pero cerradas a la modificación.)
— Bertrand Meyer, Object-Oriented Software Construction (1988); reformulado por Martin
Curiosidad: este principio es anterior a Bob — viene de Bertrand Meyer en 1988, y Bob lo reescribió con polimorfismo en mente. La idea: cuando llegue el siguiente caso de negocio, debe ser posible agregar comportamiento nuevo sin tocar el código existente.
En la práctica: si cada vez que aparece un nuevo método de pago tienes que abrir un switch con 17 casos, no respeta OCP. La solución no es “cien clases con interfaz PaymentMethod”, es que la abstracción sea natural. La trampa con OCP es sobre-aplicarlo: predecir extensiones que no van a llegar, y terminar con jerarquías de cinco niveles para una variación de configuración.
Regla pragmática: aplica OCP cuando el segundo caso aparezca, no cuando lo imagines. “Three strikes and you refactor” (Martin Fowler, Refactoring, 1999). Hasta entonces, deja el if en paz.
L — Liskov Substitution Principle (LSP)
“Subtypes must be substitutable for their base types.”
(Los subtipos deben poder sustituirse por sus tipos base.)
— Barbara Liskov, Data Abstraction and Hierarchy (OOPSLA 1987); incorporado por Martin a SOLID
Otra herencia: este principio es de Barbara Liskov, ganadora del Turing Award en 2008, formulado en una keynote de 1987. Bob lo metió a SOLID porque le importaba mantenerlo presente.
La idea: si tu función espera un Animal, y le pasas un Pato (subclase), el comportamiento no debería romperse. Suena obvio. El ejemplo clásico de violación es Square extends Rectangle: parece tener sentido (un cuadrado es un rectángulo), pero setWidth() y setHeight() ya no son independientes y código que asumía que sí lo eran, falla.
Cuándo importa LSP en la vida real: jerarquías profundas con efectos colaterales raros. Si te encuentras escribiendo if (x instanceof FooSubtype) para tratarlo distinto, acabas de violar LSP. La subclase no es realmente sustituible. Repensa la jerarquía.
I — Interface Segregation Principle (ISP)
“Clients should not be forced to depend on methods they do not use.”
(Los clientes no deberían estar forzados a depender de métodos que no usan.)
— Robert C. Martin, Agile Software Development: PPP (2002)
Si tienes una interfaz Worker con eat(), sleep(), work(), y luego implementas RobotWorker, vas a terminar lanzando excepciones en eat() y sleep(). Esa interfaz está mal cortada. Mejor tres interfaces chicas y específicas que una fat interface que ningún cliente cumple realmente.
Versión moderna y minimalista: prefiere interfaces de 2–3 métodos sobre interfaces de 12. Y prefiere “tipos de comportamiento” en vez de “objetos completos” — Go expresa esto con interfaces implícitas y tiene la convención cultural de “interfaces chicas”.
D — Dependency Inversion Principle (DIP)
“High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.”
(Los módulos de alto nivel no deberían depender de los de bajo nivel. Ambos deberían depender de abstracciones. Las abstracciones no deberían depender de detalles. Los detalles deberían depender de abstracciones.)
— Robert C. Martin, Agile Software Development: PPP (2002)
El más importante de los cinco. Y el más mal entendido. DIP no es “usa inyección de dependencias en todo”. Es: el código de negocio no debe conocer detalles de infraestructura.
Ejemplo concreto. Tu use case RegistrarCliente no debe saber si la base de datos es Postgres, MySQL o un archivo CSV. Debe declarar una abstracción tipo RepositorioClientes y la implementación concreta se enchufa después. Si mañana cambias de Postgres a Dynamo, el use case no se entera.
Esto es el corazón de Clean Architecture, su libro de 2017. Si entiendes DIP, entiendes 80% del resto.
La flecha apunta al revés que en la versión ingenua. El detalle (Postgres) depende de la abstracción (interfaz), no al revés. Eso es lo que significa “invertir” la dependencia.
El Boy Scout Rule
Una de las ideas más simples y mejor envejecidas de Bob. La frase original viene del lema scout de Robert Baden-Powell (fundador del movimiento, 1907): “Try and leave this world a little better than you found it.” Bob la adaptó al código en Clean Code (2008):
“Always leave the code cleaner than you found it.”
(Siempre deja el código un poco mejor de lo que lo encontraste.)
La lectura honesta es: cuando toques un archivo para arreglar un bug, mejora una cosita más. Renombra una variable mal llamada. Borra un comentario que mentía. Extrae una función chiquita. No refactores el archivo entero. Una mejora pequeña, en cada commit, en cinco años cambia la base de código.
La trampa: gente que entendió esto como permiso para refactorizar 40 archivos en un PR de “fix typo”. No. Boy Scout es una mejora discreta y enfocada, no una excusa para barrer la casa entera.
Las tres leyes de TDD
Bob es probablemente el evangelizador más persistente del Test-Driven Development. En su post de 2007 formuló sus famosas tres leyes:
- “You are not allowed to write any production code unless it is to make a failing unit test pass.”
- “You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.”
- “You are not allowed to write any more production code than is sufficient to pass the one failing unit test.”
- No se permite escribir código de producción salvo para hacer pasar un test que falla.
- No se permite escribir más test del necesario para fallar — los errores de compilación cuentan.
- No se permite escribir más código de producción del necesario para hacer pasar el test que falla.
Es un ciclo de segundos, no de horas. Cada 30 segundos pasas de “rojo” a “verde”. El código emerge guiado por los tests.
¿Funciona? Sí, en muchos contextos. No en todos. Donde funciona muy bien: lógica de negocio con reglas claras, librerías, código sin UI. Donde no traduce bien tal cual: prototipos exploratorios, código de UI con animaciones, integraciones con APIs externas, código de rendimiento crítico.
Matiz pragmático: TDD ortodoxo (las tres leyes a rajatabla) es excelente como disciplina de aprendizaje. Cuando ya internalizaste el ritmo, casi nadie lo aplica al pie de la letra todo el día. Lo que sí queda es escribir tests cerca del código de producción — sea antes, durante o inmediatamente después.
La controversia de 2023: Casey Muratori y Clean Code
Tienes que conocer esta porque va a salir en alguna conversación. En agosto de 2023, Casey Muratori —programador de juegos, autor de Computer Enhance, y conocido por sus videos sobre rendimiento— publicó “Clean Code, Horrible Performance”, donde mostraba con benchmarks específicos que algunas recomendaciones literales de Clean Code producen código entre 1.5x y 25x más lento que código directo y procedural equivalente.
Las recomendaciones que examinó:
- Polimorfismo por defecto en vez de
switch. - Funciones muy pequeñas por encima de funciones más grandes pero claras.
- Encapsular sobre exponer estructuras de datos directamente.
Muratori no estaba diciendo “Bob está equivocado en todo”. Estaba diciendo: estas reglas se vendieron como universales y no lo son. En código de rendimiento crítico —juegos, simulación, sistemas de tiempo real, hot paths de servidores— aplicarlas literalmente te cuesta caro.
La discusión se volvió pública. Bob respondió en LinkedIn y en una llamada por teléfono con Muratori que se publicó por escrito. La conclusión razonable de ambos lados:
- El consejo de Bob aplica al 95% del código que la mayoría de programadores escribimos — código de aplicación, lógica de negocio, ETL, servicios web normales. En ese contexto, claridad > rendimiento.
- El consejo de Bob no aplica al 5% restante — código de hot path, motores de juego, sistemas embebidos, kernels. Ahí la claridad sirve para que alguien entienda el código, pero el código tiene que ser rápido primero.
Si trabajas en el 95%, lee Clean Code sin culpa. Si trabajas en el 5%, lee Casey Muratori también, y aplica criterio.
Las citas que sí vale guardar
Estas son las frases de Bob que vas a escuchar más, todas verificables en sus libros:
Sobre por qué la legibilidad importa:
“The ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code.”
(El ratio de tiempo leyendo vs. escribiendo es mucho más de 10 a 1. Constantemente leemos código viejo como parte del esfuerzo de escribir código nuevo.)
— Clean Code (2008), capítulo 1.
Sobre los comentarios:
“Don’t comment bad code—rewrite it.”
(No comentes el código malo — reescríbelo.)
— Originalmente de Brian Kernighan & P. J. Plauger, The Elements of Programming Style (1974); citado y popularizado por Bob en Clean Code.
Sobre la responsabilidad profesional:
“Professionalism means taking responsibility.”
(Profesionalismo significa hacerse responsable.)
— The Clean Coder (2011), capítulo 2.
Sobre arquitectura, la frase que vale guardar:
“The goal of software architecture is to minimize the human resources required to build and maintain the required system.”
(La meta de la arquitectura de software es minimizar los recursos humanos necesarios para construir y mantener el sistema.)
— Clean Architecture (2017), capítulo 1.
Esa última es probablemente su mejor frase. Lee con cuidado: la arquitectura no es para que el sistema sea elegante, ni rápido, ni admirado por otros arquitectos. Es para que menos gente tenga que sufrir trabajándolo a futuro. Es una métrica concreta y humana, no estética.
El playbook pragmático
Si tuvieras que aplicar Uncle Bob de la forma más pragmática posible —sin volverte el evangelista insoportable de la oficina—, esto es lo que vale la pena retener:
| Principio | Cuándo aplicar | Cuándo ignorar |
|---|---|---|
| SRP (una razón para cambiar) | Cuando una clase empieza a tener métodos que sirven a 2+ áreas de negocio | Clases pequeñas y cohesivas que ya hacen una sola cosa |
| OCP (cerrado a modificación) | Después del segundo caso real, no del primero | Cuando estás imaginando extensiones que no han llegado |
| LSP (subtipos sustituibles) | Siempre que tengas herencia y polimorfismo activos | Casi nunca aplicable si usas composición sobre herencia |
| ISP (interfaces chicas) | Sí, casi siempre. Cuesta poco | Nunca contraindicado |
| DIP (depender de abstracciones) | En todo código que cruza una frontera (DB, API externa, servicio) | En utilidades puras y locales — sería sobre-ingeniería |
| Boy Scout Rule | Siempre, en mejoras chicas | Como excusa para refactors masivos |
| TDD ortodoxo (3 leyes) | Lógica de negocio con reglas claras; aprendizaje | Prototipos, código de UI animado, hot paths |
| Funciones muy chicas (4 líneas) | Cuando ayudan a leer | Cuando fragmentar oculta la intención |
| No comentarios | El 70% de los comentarios son redundantes | Cuando explican un por qué no obvio |
Lo que sí vale conservar de Uncle Bob, después de todo
A pesar de los matices, hay tres cosas que Bob aportó al oficio y que 20 años después siguen siendo verdad:
- Que el código es para humanos. Si tu equipo no lo puede leer en una mañana, tu código tiene un problema, aunque pase los tests.
- Que SOLID no es decoración OO. Especialmente DIP — invertir las dependencias entre negocio e infraestructura es la diferencia entre un sistema que se puede modificar 5 años después y uno que hay que tirar.
- Que la disciplina es individual. Ningún proceso, framework o ceremonia te salva de escribir código sucio. La calidad nace del programador uno por uno, todos los días, en cada commit.
Si te quedas con esto, te llevas más de lo que sacan muchos lectores que se lo memorizaron.
Lecturas que sí valen la pena
- Robert C. Martin (2002), Agile Software Development: Principles, Patterns, and Practices (Prentice Hall) — el origen escrito de SOLID. Denso, sobrio, muy buen libro de principios.
- Robert C. Martin (2008), Clean Code: A Handbook of Agile Software Craftsmanship (Prentice Hall) — el más leído. Léelo con criterio, no como dogma.
- Robert C. Martin (2011), The Clean Coder: A Code of Conduct for Professional Programmers (Prentice Hall) — sobre profesionalismo y disciplina personal. Polémico pero útil.
- Robert C. Martin (2017), Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Pearson) — el mejor para entender por qué importa la arquitectura.
- Bertrand Meyer (1988), Object-Oriented Software Construction — donde nació el Open/Closed Principle. Fundamental.
- Barbara Liskov & Jeannette Wing (1994), A Behavioral Notion of Subtyping (ACM TOPLAS) — el paper formal del LSP.
- Michael Feathers (2004), Working Effectively with Legacy Code (Prentice Hall) — el complemento práctico de Bob para código real, no greenfield.
- Casey Muratori (2023), “Clean Code, Horrible Performance” — la crítica indispensable para entender los límites del consejo.
- Brian Kernighan & P. J. Plauger (1974), The Elements of Programming Style (McGraw-Hill) — el abuelo de todos estos libros. Más corto y casi todas las ideas ya están ahí.
Y si te llevas una sola idea: el código se escribe una vez y se lee mil veces. Cualquier práctica que reduzca el costo del segundo trayecto, vale la pena, aunque cueste un poco más en el primero. El resto es discusión sobre dónde está exactamente esa línea.