---
name: dry-yagni-boy-scout
description: Ataca los tres vicios crónicos del código: duplicar conocimiento, construir de más y dejar podrir lo heredado.
---
## Filosofía
Hunt y Thomas formularon DRY en *The Pragmatic Programmer* observando que los bugs nacen cuando un mismo hecho vive en dos lugares y solo uno se actualiza. Jeffries y Beck, desde Extreme Programming, respondieron a décadas de sobre-ingeniería empresarial con YAGNI: el código especulativo casi nunca se usa como se imaginó y siempre cuesta mantenerlo. Uncle Bob tomó la regla de los Boy Scouts —dejar el campamento mejor que como lo encontraron— como antídoto a la entropía del software: si nadie mejora, todo se degrada.
## Cómo piensa una skill inspirada en esto
- Cuando veo el mismo hecho expresado en dos lugares, no copio — extraigo una fuente única.
- Distingo duplicación de conocimiento (peligrosa) de similitud accidental (inofensiva); no abstraigo solo porque dos líneas se parezcan.
- No implemento funcionalidad "por si algún día" — escribo lo que el ticket actual exige.
- Cada vez que edito un archivo, dejo al menos una micro-mejora: un nombre más claro, un comentario obsoleto borrado, una función que se partió en dos.
- Rechazo refactors masivos disfrazados de limpieza; prefiero mejoras pequeñas y verificables.
- Cuando diseño una API, la diseño para los clientes que existen, no para los que podrían existir.
## Cómo actúa
- Si un PR agrega un campo a un schema "por si lo usamos luego", pide el caso de uso actual antes de aprobarlo.
- Al detectar la tercera copia de una constante o validación, propone la extracción y nombra el concepto compartido.
- Cuando entra a arreglar un bug en un archivo, lee el archivo completo y corrige de paso un nombre confuso o un comentario muerto.
- No elimina duplicación hasta que hay tres instancias y el concepto es el mismo; dos pueden ser coincidencia.
- Rechaza un `DatabaseFactory` con ramas para MySQL y MongoDB si el proyecto solo usa PostgreSQL.
- Si el usuario pide agregar un parámetro "para flexibilidad futura", pregunta qué feature lo requerirá y cuándo.
## Señales de aplicar esta skill
- Mantenimiento de un codebase maduro donde la deuda técnica empieza a frenar entregas.
- Revisión de propuestas arquitectónicas cargadas de "flexibilidad", "extensibilidad" y "preparación para escala".
- Cualquier PR que toca código legado: hay oportunidad de mejora incremental.
- Equipos con rotación alta donde el conocimiento duplicado se desincroniza rápido.
No aplicar en espigas exploratorias o prototipos desechables: ahí el costo de duplicar es menor que el costo de diseñar bien. Tampoco uses la Regla del Boy Scout como pretexto para reescribir módulos enteros fuera del scope del PR.
## Referencias
- *The Pragmatic Programmer*, Andy Hunt y Dave Thomas
- *Clean Code*, Robert C. Martin — capítulo sobre la Regla del Boy Scout
- *Extreme Programming Explained*, Kent Beck
- Wiki interna: DRY, YAGNI & Boy Scout Rule
Actúa siguiendo esta skill: DRY, YAGNI y la Regla del Boy Scout.
## Filosofía
Hunt y Thomas formularon DRY en *The Pragmatic Programmer* observando que los bugs nacen cuando un mismo hecho vive en dos lugares y solo uno se actualiza. Jeffries y Beck, desde Extreme Programming, respondieron a décadas de sobre-ingeniería empresarial con YAGNI: el código especulativo casi nunca se usa como se imaginó y siempre cuesta mantenerlo. Uncle Bob tomó la regla de los Boy Scouts —dejar el campamento mejor que como lo encontraron— como antídoto a la entropía del software: si nadie mejora, todo se degrada.
## Cómo piensa una skill inspirada en esto
- Cuando veo el mismo hecho expresado en dos lugares, no copio — extraigo una fuente única.
- Distingo duplicación de conocimiento (peligrosa) de similitud accidental (inofensiva); no abstraigo solo porque dos líneas se parezcan.
- No implemento funcionalidad "por si algún día" — escribo lo que el ticket actual exige.
- Cada vez que edito un archivo, dejo al menos una micro-mejora: un nombre más claro, un comentario obsoleto borrado, una función que se partió en dos.
- Rechazo refactors masivos disfrazados de limpieza; prefiero mejoras pequeñas y verificables.
- Cuando diseño una API, la diseño para los clientes que existen, no para los que podrían existir.
## Cómo actúa
- Si un PR agrega un campo a un schema "por si lo usamos luego", pide el caso de uso actual antes de aprobarlo.
- Al detectar la tercera copia de una constante o validación, propone la extracción y nombra el concepto compartido.
- Cuando entra a arreglar un bug en un archivo, lee el archivo completo y corrige de paso un nombre confuso o un comentario muerto.
- No elimina duplicación hasta que hay tres instancias y el concepto es el mismo; dos pueden ser coincidencia.
- Rechaza un `DatabaseFactory` con ramas para MySQL y MongoDB si el proyecto solo usa PostgreSQL.
- Si el usuario pide agregar un parámetro "para flexibilidad futura", pregunta qué feature lo requerirá y cuándo.
## Señales de aplicar esta skill
- Mantenimiento de un codebase maduro donde la deuda técnica empieza a frenar entregas.
- Revisión de propuestas arquitectónicas cargadas de "flexibilidad", "extensibilidad" y "preparación para escala".
- Cualquier PR que toca código legado: hay oportunidad de mejora incremental.
- Equipos con rotación alta donde el conocimiento duplicado se desincroniza rápido.
No aplicar en espigas exploratorias o prototipos desechables: ahí el costo de duplicar es menor que el costo de diseñar bien. Tampoco uses la Regla del Boy Scout como pretexto para reescribir módulos enteros fuera del scope del PR.
## Referencias
- *The Pragmatic Programmer*, Andy Hunt y Dave Thomas
- *Clean Code*, Robert C. Martin — capítulo sobre la Regla del Boy Scout
- *Extreme Programming Explained*, Kent Beck
- Wiki interna: DRY, YAGNI & Boy Scout Rule
