Nivel 6 · En la práctica

6.3Buenas prácticas y trampas

Objetivo: adoptar los buenos reflejos de construcción, de datos y de entrega, y reconocer las trampas habituales.

Tiempo estimado: 10 min · Si solo tienes 5 min: lee «Lo esencial en 30s» + el esquema.

Lo esencial en 30 segundos

Preparar: un análisis limpio y ventanas vinculadas valen más que parches acumulados.
Proteger: transacciones, derechos, copias de seguridad y pruebas en máquina virgen evitan pérdidas de datos y entregas azarosas.
Documentar: un cuaderno de incidentes y versiones seguidas transforman un proyecto en solitario en una aplicación mantenible.

Hilo Yacine — los reflejos que aguantaron

Tras varios años en la aplicación del comercio, Yacine ha retenido algunos reflejos sencillos: analizar antes de programar, vincular los campos en lugar de apañar, acotar las consultas, enmarcar las escrituras y validar cada entrega. Las trampas, en cambio, vuelven siempre por los mismos caminos: la prisa y los atajos no documentados.

Las buenas prácticas no son reglas para quedar bien: cada una evita una avería o una pérdida de tiempo conocida.

Lo que marca la diferencia

Dos aplicaciones pueden tener la misma pantalla y un destino muy distinto. Lo que las separa son decisiones discretas: un análisis claro, campos vinculados, consultas acotadas, transacciones y una validación seria. Esas decisiones no se ven en la demo — se ven seis meses después.

Las trampas clásicas

La mayoría de los incidentes evitables vienen de atajos: programar antes de analizar, filtrar en la pantalla en lugar de en la base, olvidar los derechos, entregar sin prueba en máquina virgen o actualizar sin copia de seguridad. Cada uno parece ahorrar una hora; cada uno puede costar un día.

Aguantar en el tiempo

Una aplicación mantenible se reconoce por su documentación y su trazabilidad: un cuaderno de incidentes, versiones seguidas, copias de seguridad y procedimientos de despliegue conocidos. Es también lo que permite a un nuevo desarrollador retomar el proyecto sin romperlo todo.

✓ Qué hacer

Concebir el análisis (archivos, rúbricas, enlaces, claves) antes de abrir la primera ventana.
Vincular los campos a las rúbricas y dominar HAjoute, HModifie y HEnDehors.
Filtrar y acotar las consultas del lado de la base, y verificar la indexación.
Enmarcar las escrituras sensibles con transacciones y definir los derechos por rol.
Validar cada versión en una máquina virgen y hacer copia de seguridad antes de cualquier actualización.

✗ Qué evitar

Programar las ventanas primero e improvisar los datos después.
Hacer la ordenación y el filtro en WLangage sobre todo el archivo en lugar de en la base.
Dejar los derechos solo en el nivel de la pantalla, sin control en el servidor.
Enviar el ejecutable solo sin dependencias ni prueba en un puesto limpio.
Actualizar en producción sin copia de seguridad ni vuelta atrás posible.

Error frecuente de interpretación: «las buenas prácticas ralentizan». No. Cuestan unos minutos hoy y evitan días de diagnóstico mañana. El verdadero coste es la avería en producción un viernes por la noche, sin copia de seguridad ni vuelta atrás.

Versión en texto del esquema (SEO / lectores de pantalla / traducción): 1) Analizar antes de programar. 2) Vincular los campos y controlar los registros. 3) Filtrar y acotar del lado de la base, indexar. 4) Enmarcar las escrituras y definir los derechos. 5) Validar en máquina virgen. 6) Hacer copia de seguridad antes de cualquier actualización. Lección: la fiabilidad viene de reflejos repetidos, no de una hazaña puntual.

Guion listo para decir — defender una validación (30 s)

«Antes de entregar, valido en una máquina virgen: conexión, introducción, modificación, supresión, derechos e impresión. Eso es lo que evita descubrir un problema en casa del cliente.»

Para guardarlo y justificar el tiempo de prueba ante un jefe con prisa.

Guion listo para decir — explicar una copia de seguridad (30 s)

«Siempre hago copia de seguridad antes de una actualización, y verifico que la restauración funciona. Sin eso, una conversión fallida puede costar los datos del mes.»

Útil para encuadrar una intervención en producción.

Modelo para copiar y pegar — checklist de entrega

1. Análisis al día + migración probada sobre copia
2. Campos vinculados + recorrido de guardado OK
3. Consultas acotadas + índices verificados
4. Derechos por rol probados con perfiles reales
5. Validación en máquina virgen (instalación incluida)
6. Copia de seguridad hecha + vuelta atrás prevista
7. Versión numerada + nota de entrega

Modelo para copiar y pegar — regla de filtrado

// Qué hacer: filtrar del lado de la base
SQLExec("SELECT * FROM Produits WHERE Famille = {pFamille}")
// Qué evitar: traerlo todo y luego filtrar
HLitRecherche(Premier, Produits)
TANTQUE HEnDehors(Produits) = Faux
    SI Produits.Famille = pFamille ALORS ...
    HLitSuivant(Produits)
FIN

Microempresa / presupuesto ajustado

Mantener lo esencial: análisis claro, campos vinculados, copia de seguridad antes de actualizar y validación mínima en un puesto limpio.

PYME Orán

Adaptar a las realidades locales: material heterogéneo, formación corta de los usuarios y procedimientos escritos en francés sencillo.

Remoto / multisitio

Reforzar la trazabilidad: versiones numeradas, registros centralizados y procedimiento de actualización a distancia documentado.

Intercultural

Hacer explícitas las reglas implícitas (derechos, copias de seguridad, validación) para que sobrevivan al cambio de equipo.

Prudencia: Recordatorio genérico: una actualización o un despliegue toca datos reales. Haga copia de seguridad antes de cualquier intervención, pruebe la conversión sobre una copia representativa y prevea una vuelta atrás. La protección de los datos personales de los clientes depende de obligaciones legales que varían según los países: infórmese sobre el derecho aplicable y asesórese — esta guía no es un dictamen jurídico.

Reto 48 h — aplícalo mañana

Tome una entrega real y aplique la checklist: análisis al día, consultas acotadas, derechos probados, validación en máquina virgen y copia de seguridad previa.

Lista de salida de la sección

Conozco los reflejos que fiabilizan una aplicación y las trampas que hay que evitar.
Tengo una checklist de entrega y una regla de filtrado reutilizables.
He hecho el reto de 48 h o he planificado su fecha.

Autoevaluación 1-5: ¿sacrifico la validación para ganar una hora?¿hago copia de seguridad sistemáticamente antes de una actualización?

← Anterior : Problemas recurrentes (playbook) (V3)Siguiente : Caja de herramientas (V3) →

Comprueba tu comprensión

¿Qué reflejo reduce más los incidentes de entrega en casa del cliente?

💡

Las buenas prácticas no son reglas para quedar bien: cada una evita una avería o una pérdida de tiempo conocida.