Enlaces
Ejemplos Clean Code en Typescript
Testing
Clean Architecture
Regla de oro
“Make it work → make it right → make it fast”
Empieza simple. Que funcione. Luego, si tienes tiempo, refactorizas.
No te obsesiones. Lo que hoy es una buena práctica, mañana puede quedar obsoleto. Más importante que seguir todas las reglas es entender por qué existen. Cuando entiendes el “por qué”, puedes decidir cuándo seguir una regla y cuándo romperla con intención.
Mejora progresiva en lugar de perfección total
No intentes aplicar todos los principios SOLID, TDD, patrones de diseño, arquitectura hexagonal y CI/CD perfectos a la vez. En lugar de eso:
-
Elige una cosa a mejorar cada vez (por ejemplo, pruebas automatizadas).
-
Mejora con cada nuevo proyecto o feature.
-
Revisa tu propio código con preguntas simples como: ¿será fácil mantener esto en 6 meses?
Criterio práctico
El código limpio no es el que parece sofisticado. Es el que reduce carga mental.
Antes de abstraer, pregúntate:
- ¿Esto hace más claro el comportamiento?
- ¿Esto reduce duplicación real o solo anticipa una posibilidad?
- ¿Esto será más fácil de cambiar cuando el requisito cambie?
- ¿Esto se puede testear sin montar media aplicación?
Checklist de revisión
- Los nombres explican intención, no implementación.
- Cada función hace una cosa reconocible.
- Las funciones mezclan el menor número posible de niveles de abstracción.
- Los errores se tratan explícitamente.
- La duplicación eliminada representa conocimiento duplicado, no solo líneas parecidas.
- Los comentarios explican decisiones, no repiten el código.
- Las dependencias externas están en los bordes.
- Hay tests donde un cambio podría romper comportamiento importante.
Tests como parte del clean code
Los tests no son una fase aparte. Son una herramienta de diseño.
Un código difícil de testear suele indicar una de estas cosas:
- Demasiadas responsabilidades en la misma función.
- Dependencias externas mezcladas con lógica de negocio.
- Estado global difícil de controlar.
- Efectos secundarios escondidos.
- Abstracciones que no representan conceptos reales.
No todo necesita el mismo nivel de test. Lo crítico es proteger comportamiento, reglas de negocio y bugs que ya aparecieron una vez.
Notas sobre el libro
Algunas notas e ideas que me han resultado interesantes o inspiradoras:
Imagine que es médico y un paciente le exige que no se lave las manos antes de una operación porque se pierde demasiado tiempo. En este caso, el paciente es el jefe, pero el médico debe negarse a lo que pide. ¿Por qué? Porque le médico sabe más que el paciente sobre los riegos de infecciones. No sería profesional que el médico cediera a las exigencias del paciente. Tampoco sería profesional que los programadores cedieran a la voluntad de los jefes que no entienden los riesgos de un posible desastre.
A veces hay que saber plantarse y decirle a un cliente NO.
El clean code se puede leer y mejorar por parte de un programador que no sea su autor original.
El clean code es aquél al que se le ha dado importancia. Alguien ha dedicado su tiempo para que sea sencillo y ha prestado atención a los detalles. Se ha preocupado
Debo escribir código como si tuviese a alguien detrás leyendo y juzgando, porque la realidad es que en algún momento ese código pasará a manos de otra persona.
Si quiere avanzar rápidamente, terminar cuando antes y que su código sea fácil de escribir, haga que sea fácil de leer.
Deja de usar la excusa de ‘Los plazos son muy ajustados, hagamos las cosas rápido y mal’. Es chapucero y a la larga, lidiar con esa chapuza acaba siendo más costoso.
Una diferencia entre un programador inteligente y un programador profesional es que este último sabe que la claridad es lo que importa.
Prioriza lectura sobre ‘smart code’.
Al sobrecargar Constructores, use métodos de factoria estáticos con nombres que describan los argumentos.