Este es un proyecto de Vanilla TypeScript en Vite, para trabajar los ejercicios del curso sobre Principios SOLID y CleanCode.
Clonar o descargar el proyecto y luego:
yarn install
ó
npm install
Para ejecutar el proyecto, simplemente ejecuten
yarn dev
ó
npm run dev
Este curso:
- ❌ No es para aprender a programar.
- ❌ No es para aprender JavaScript o TypeScript.
- ✅ Es para practicar y aprender buenas prácticas para el manejo de nuestro código.
- ✅ Busca reducir la deuda técnica.
- ✅ Aplica a cualquier lenguaje de programación.
La falta de calidad en el código que genera una deuda que repercutirá en costos futuros.
- ⏳ Tiempo en mantenimiento.
- 🔄 Tiempo en refactorización.
- 🤯 Tiempo en comprender código legado.
- 🔁 Tiempo adicional en transferencia de conocimiento.
- 💸 Costos económicos.
Caer en deuda técnica es normal y muchas veces inevitable.
Proceso que mejora el código sin alterar su comportamiento, haciéndolo:
- Más entendible
- Más mantenible
- Más tolerante a cambios
“Si funciona, no lo toques” — mentalidad común cuando no hay tests.
“Código limpio es aquel que se ha escrito con la intención de que otra persona (o tú mismo en el futuro) lo entienda.” – Carlos Blé
“Nuestro código tiene que ser simple y directo.” – Grady Booch
“Programar es el arte de decirle a otro humano lo que quieres que la computadora haga.” – Donald Knuth
- Deben ser pronunciables y expresivos.
- Sin información técnica innecesaria.
- Según el tipo de dato.
- Claros y autoexplicativos.
- Usar UpperCamelCase
- Formadas por sustantivos
- No demasiado genéricas
- ¿Qué hace exactamente la clase?
- ¿Cómo realiza su tarea?
- ¿Hay algo específico sobre su ubicación?
“Sabemos que estamos desarrollando código limpio cuando cada función hace exactamente lo que su nombre indica.” – Ward Cunningham
- Simplicidad ante todo
- Tamaño reducido
- Idealmente menos de 20 líneas
- Evitar
else - Priorizar condicional ternaria
- Limitar a 3 parámetros posicionales
Don’t Repeat Yourself
- Evitar duplicidad de código
- Simplifica pruebas
- Centraliza procesos
- Refactorizar cuando sea necesario
“Si quieres ser un programador productivo esfuérzate en escribir código legible.” – Robert C. Martin
Orden recomendado:
- Propiedades estáticas
- Propiedades públicas
- Constructores estáticos
- Constructor
- Métodos estáticos
- Métodos privados
- Métodos públicos (de mayor a menor importancia)
- Getters y Setters
“El buen código parece estar escrito por alguien a quien le importa.” – Michael Feathers
- Deben ser la excepción, no la regla.
- Preferir código autoexplicativo.
- Comentar el por qué, no el qué ni el cómo.
“No comentes el código mal escrito, reescríbelo.” – Brian W. Kernighan
- Problemas similares → soluciones similares
- Mantener indentación consistente
- Mantener estilo uniforme en el proyecto
- S – Singleton
- T – Tight Coupling (Alto acoplamiento)
- U – Untestability (No testeable)
- P – Premature Optimization (Optimización prematura)
- I – Indescriptive Naming (Nombres poco descriptivos)
- D – Duplication (Duplicidad)
- Garantiza una única instancia
- Vive en contexto global
- Difícil de testear
- No es rastreable
- Puede modificarse desde cualquier lugar
- Efecto dominó en cambios
- Dificultad para reutilizar
- Dificultad para testear
- Alta cohesión → clase enfocada en una responsabilidad clara
- Baja cohesión → clase hace demasiadas cosas
Causas:
- Alto acoplamiento
- Dependencias no inyectadas
- Uso de singletons
Siempre pensar en tests desde el inicio.
No anticiparse a requisitos.
- ❌ Añade complejidad accidental
- ✅ Mantener opciones abiertas
- Variables mal nombradas
- Clases genéricas
- Funciones ambiguas
La única medida de calidad es el “WTF por minuto”.
- Código idéntico
- Cambios múltiples necesarios
- Mayor probabilidad de errores
- Código similar pero con distinta función
- Puede resolverse con parámetros o abstracciones
- Inflación
- Obsesión primitiva
- Lista larga de parámetros
- Feature Envy
- Intimidad inapropiada
- Cadenas de mensajes
- The Middle Man
- S – Single Responsibility
- O – Open/Closed
- L – Liskov Substitution
- I – Interface Segregation
- D – Dependency Inversion
“Nunca debería haber más de un motivo por el cual cambiar una clase.”
No significa hacer una sola cosa, sino tener una única responsabilidad.
- Clase demasiado genérica
- Muchas importaciones
- Muchas responsabilidades
- Demasiadas líneas
- Abierto para extensión
- Cerrado para modificación
Evitar modificar código existente para nuevos comportamientos.
Se puede lograr mediante:
- Herencia
- Composición
- Patrón Strategy
“Si U es subtipo de T, entonces debe poder sustituirse sin alterar el sistema.”
Las subclases deben comportarse correctamente en lugar de la clase base.
“Los clientes no deberían depender de interfaces que no utilizan.”
Interfaces pequeñas y específicas.
“Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones.”
- Dominio no debe depender de infraestructura.
- UI y DB deben depender de abstracciones.
- Usar inyección de dependencias.
- Componentes de dominio son los más importantes.
- Infraestructura (UI, DB, APIs) son detalles.
- Los detalles deben depender de abstracciones.
Un módulo requiere otro para funcionar.
Cuando la aplicación crece, debemos usar inyección de dependencias para:
- Reducir acoplamiento
- Mejorar testabilidad
- Facilitar cambios
Un buen diseño de software:
- Tiene alta cohesión
- Tiene bajo acoplamiento
- Sigue principios SOLID
- Evita code smells
- Prioriza legibilidad
- Reduce deuda técnica