6.4Checklists y modelos
Lo esencial en 30 segundos
- Al arrancar : LTS verificado, package.json + scripts, capas decididas, base elegida, async/await en todas partes.
- Antes de producción : entradas validadas, seguridad completa, secretos en .env, tests en verde, logs y escalado.
- Regla : una checklist marcada cada vez vale más que un método sabido de memoria — en rush, se ejecuta.
Hilo Salim — las fichas a mano
Tras un año, las dos fichas siguientes están expuestas en casa de Salim : la de arranque junto a la pantalla, la de puesta en producción en su cajón con el contacto del referente. « Lo que me salvó, dice en sustancia, no es conocer los puntos, es marcarlos cada vez — sobre todo las semanas de rush. »
Adapta las formulaciones a tu contexto, conserva la estructura : es ella la que evita olvidos e incidentes.
Dos listas para guardar a mano
Una checklist al arrancar un proyecto Node, una antes de la puesta en producción. Transforman los buenos reflejos en rutina verificable.
Al arrancar un proyecto Node
- Node LTS instalado y verificado (node -v / npm -v) ; VS Code con ESLint/Prettier.
- npm init, package.json + scripts ; .gitignore (node_modules, .env).
- Estructura por capas decidida (routes / controllers / models / services).
- Elección de la base (MongoDB/Mongoose o SQL/Prisma) y esquema validado.
- Convención asíncrona : async/await en todas partes, nunca una llamada síncrona bloqueante en servidor.
Antes de la puesta en producción
- Entradas validadas (Zod/Joi) y gestión centralizada de errores en su lugar.
- Seguridad : contraseñas cifradas (bcrypt), JWT verificado, autorización, Helmet, HTTPS.
- Secretos y configuración en variables de entorno (nunca en el código ni Git).
- Tests (Jest) en verde y pipeline CI/CD que prueba antes de desplegar.
- Logs y monitoring, entornos separados (dev/staging/prod), plan de escalado (clustering/PM2).
Guion listo para decir — validar una puesta en producción (30 s)
« ¿Entradas validadas y errores centralizados ? ¿bcrypt, JWT, autorización, Helmet, HTTPS ? ¿Secretos en .env fuera de Git ? ¿Tests Jest en verde y CI/CD ? ¿Logs, entornos separados, escalado ? Si un no, no se pone en producción. »
Modelo copiar-pegar — seguimiento arranque + producción (1 línea por punto)
// Seguimiento : pasar cada línea a OK antes de continuar
const suivi = [
"LTS + VS Code (ESLint/Prettier) : OK / a retomar",
"package.json + scripts + .gitignore : OK / a retomar",
"Capas + base + esquema validado : OK / a retomar",
"Async/await en todas partes : OK / a retomar",
"Validación + errores + bcrypt + JWT + Helmet : OK / a retomar",
"Secretos en .env fuera de Git : OK / a retomar",
"Jest en verde + CI/CD : OK / a retomar",
"Logs + dev/staging/prod + clustering : OK / a retomar"
];
module.exports = suivi;Pyme muy pequeña / bajo presupuesto
Fichas en una página expuesta en la pared : lo esencial (LTS, capas, validación, .env, tests) basta.
Pyme Argelia
Prever las realidades locales en la ficha : referentes conocidos, picos, desplazamientos, copias de seguridad verificadas.
Remoto / híbrido
Añadir una línea de confirmación escrita al seguimiento : a distancia, una puesta en producción fechada y validada evita malentendidos.
Intercultural
Explicitar los títulos por escrito : lo que parece evidente (quién valida, qué entorno) no lo es para todos.
Reto 48h — aplica mañana
Toma 1 proyecto real, pasa la checklist « al arrancar » y marca dónde está. Anota el referente en la ficha producción.
- Marqué una checklist sobre un proyecto real.
- Sé sacar el arranque y el antes-de-producción en el buen momento.
- Hice el reto 48h o planifiqué su fecha.
Salim se dispone a poner su API en producción. ¿Qué debe marcar con prioridad ?
Truco : estas checklists evitan lo esencial de los incidentes — servidor bloqueado, datos no validados, secreto filtrado, regresión no detectada, despliegue fallido.