¡Buenas!
Resumen de este email:
- Cuando sí duplicamos código (+ curso de 4 reglas del diseño simple publicado en plan Premium)
- ¿Vamos a dejar de utilizar cursor?
Tiempo estimado de lectura: 3 minutos.
⌨️ Cuando sí duplicamos código
> Uno de los mayores males programando es duplicar código. - Por eso creamos abstracciones. > Pero más vale tener código duplicado que una mala abstracción. - Por eso duplicamos código.
Esta es una contradicción que nos encontramos muchas veces programando, pero… ¿cuándo duplicar código y cuándo abstraer?
Aquí nos podemos apoyar en 3 principios: - DRY - WET - SSOT
DRY: Don't Repeat Yourself > Cada pieza de código o lógica debería tener una única representación en el sistema.
La idea central es evitar repartir la misma lógica en diversos sitios para ganar cohesión.
Es muy útil para cuando tenemos mucho conocimiento del código y sabemos que una abstracción en un momento determinado nos va a ahorrar problemas futuros.
Esta regla no significa 0 duplicación literal, sino evitar duplicar conocimiento (reglas de negocio, comportamientos…), lo cual evita que se desincronice.
WET: Write Everything Twice > También conocida como la regla del 3. No hagas una abstracción hasta la 3a vez que veas el código duplicado.
No significa siempre duplicar, sino esperar a encontrar patrones estables antes de abstraer.
Es útil cuando no conocemos bien la base de código o el código evoluciona muy rápidamente. Al esperarnos a esas 3 veces, veremos si tiene sentido hacer la abstracción o quizás mejor mantenerlo duplicado porque el código va a evolucionar de manera diferente.
SSOT: Single Source of Truth > Es un principio que indica que cada dato o pieza de información debe existir en un único lugar autorizado dentro del sistema.
Es muy útil aplicarlo en ficheros de configuraciones. Es mejor tener un sólo fichero de configuración y declarar allí los parámetros de conexión a la base de datos que tener n ficheros y las líneas de conexión duplicadas.
Como resumen, por regla general, nosotros duplicamos cuando no sabemos cómo va a evolucionar el código.
Para ello aplicamos la regla del 3.
Para ficheros de config u otros donde estamos muy seguros que queremos una centralización, creamos una abstracción.
Todo esto y más lo contamos en el curso de curso de 4 reglas del diseño simple que acabamos de publicar al 100% en el plan premium. 😊
💻 ¿Vamos a dejar de utilizar cursor?
Este año está siendo el año de los agentes para programar. Desde que Cursor los introdujo sobre marzo, la forma de programar ha cambiado bastante.
Y el modelo de precios también.
Cursor se hizo popular por sus precios: 20$/mes y tienes acceso casi ilimitado. La forma de uso era por cada petición que hacías. Tenías X uso de la IA al mes.
Desde entonces hasta ahora, los agentes han pasado de poder editar un par de ficheros a hacer PRs enteras. No sigue teniendo sentido para cursor que siga valiendo lo mismo, ya que una petición de marzo costaba Y, una de ahora cuesta Y*10.
Nosotros tenemos contratado, entre otros IDEs, el plan anual de Cursor, pero con el cambio de formato, quizás no tiene sentido seguir allí. Mañana a las 9h CEST, en el Café con Codely, comentaremos cómo son nuestros pensamientos sobre el tema ahora mismo. Puedes seguirlo en YouTube o Twitch.
Y ya que has llegado hasta esta parte de la newsletter, te dejo aquí el chiste de la semana, qué sé que lo estabas esperando:
> ¿Por qué los containers de Docker no tienen amigos? Porque siempre están aislados. 😂
¡Un saludo!