name: diseñar-antes-de-construir description: Úsalo al iniciar una funcionalidad, corregir un error no trivial o estar a punto de escribir código de implementación, antes de que exista cualquier código. Síntomas que indican que lo necesitas: "esto es simple, solo lo codificaré", alcanzar el editor antes de que se apruebe un diseño, o una idea que aún no se ha convertido en especificación y plan.
Diseñar antes de construir
Resumen
El trabajo fluye a través de cinco etapas, en orden: Lluvia de ideas → Especificación → Planificación → Ejecución → Registro. No se inicia ninguna implementación antes de que se haya articulado y aprobado un diseño. La tarea más simple es donde las suposiciones no examinadas cuestan más.
Violar la letra de esta regla es violar su espíritu. "Diseñaré mientras codifico" no es diseñar.
Las cinco etapas
- Lluvia de ideas. Explora la intención, las restricciones y los criterios de éxito. Haz una pregunta a la vez. Propón 2–3 enfoques con sus ventajas y desventajas y una recomendación. Converge en un diseño y obtén aprobación explícita. Aquí no hay código.
- Especificación. Escribe el diseño aprobado en un documento con fecha. La especificación es el contrato de lo que se va a construir.
- Planificación. Descompón la especificación en un plan de implementación ordenado y revisable antes de tocar el código.
- Ejecución. Implementa según el plan, con puntos de control de revisión.
- Registro. Destila lo que se construyó y por qué en un registro de decisiones (consulta
recording-decisions).
Descompón esfuerzos grandes. Si una solicitud abarca múltiples subsistemas independientes, detente y descompón antes de refinar los detalles. Cada subproyecto ejecuta su propio ciclo, construido en orden de dependencias.
Cuándo NO usarlo
Las ediciones genuinamente triviales y reversibles (un error tipográfico, una línea de registro, un valor de configuración) saltan directamente a Ejecución. La prueba: ¿una suposición incorrecta aquí costaría más que el paso de diseño? Si es así, diseña primero.
Racionalizaciones comunes
| Excusa | Realidad |
|---|---|
| "Esto es demasiado simple como para necesitar un diseño" | Las tareas simples ocultan suposiciones. Unas pocas frases de diseño son baratas; una reescritura no. |
| "Diseñaré sobre la marcha" | El código escrito antes de que el diseño esté resuelto es código reescrito. El diseño es un acto separado. |
| "El usuario me dijo qué construir, ESO es el diseño" | Una solicitud establece qué, no cómo. El cómo es el diseño. |
| "Primero exploraré el código base para conocer el enfoque" | La exploración informa el diseño; no reemplaza la aprobación de uno. |
| "Tenemos prisa" | La prisa es exactamente cuando un diseño omitido produce trabajo desechable. |
Señales de alerta — DETENTE
- Abrir el editor antes de que exista un diseño aprobado
- "Déjame hacer un prototipo rápido" (un prototipo sin especificación es alcance no revisado)
- Iniciar un cambio de múltiples archivos sin un plan
- Tratar la solicitud de una línea del usuario como una especificación terminada
Todas estas señales significan: detente, diseña, obtén aprobación, luego construye.
Razonamiento completo: Artículo I de la constitución, incluido en engineering-constitution/references/engineering-constitution.md.