Si escribes scripts y crees que todo va bien porque no salta un error, tienes un problema serio. La mayoría de fallos que rompen un proyecto no lanzan excepciones: se esconden en una variable mal nombrada, en un scope que no controlas o en una promesa que nunca se resuelve. Y cuando explota, ya es tarde.
He revisado código de gente que lleva años programando y sigo viendo los mismos errores. No son de novato. Son de confianza excesiva. Aquí va lo que de verdad está rompiendo tus scripts en 2026.
Qué es un script y por qué casi nadie lo entiende bien
Un script es un conjunto de instrucciones que se ejecutan dentro de un programa anfitrión. No es un ejecutable independiente. Necesita un intérprete: el navegador, Node, Bash, PowerShell o el motor de Excel. Esa dependencia del entorno es justo lo que provoca la mitad de los fallos silenciosos.
El error clásico: asumir que tu script funciona igual en local que en producción. En tu máquina tienes la versión 20 de Node, en el servidor la 16. Tu script usa fetch nativo, y en producción revienta sin decirte por qué. Eso es un script roto que tú no ves.
Los scripts no son autónomos. Y quien no lo interioriza, acaba depurando a ciegas. Un script bien escrito declara sus dependencias, controla la versión del intérprete y falla rápido cuando algo no cuadra.
Los 5 errores que están saboteando tus scripts ahora mismo
Voy al grano, porque aquí está el oro. Estos son los fallos que veo cada semana y que la gente no detecta hasta que el sistema se cae.
- Variables globales por pereza. Declaras todo con var o sin declarar y contaminas el scope global. En un script pequeño no pasa nada. Cuando crece, dos funciones pisan la misma variable y el resultado es impredecible.
- No capturar errores asíncronos. Un await sin try/catch es una bomba de relojería. Si la API externa tarda o devuelve 500, tu script se queda colgado y tú ni te enteras.
- Confiar en el orden de ejecución. JavaScript no ejecuta todo en el orden en que lo lees. El event loop reordena. Si tu script depende de que una llamada termine antes que otra sin usar await, estás jugando a la ruleta.
- Hardcodear rutas y credenciales. Funciona en tu PC. En el servidor de otro, no. Y si subes eso a GitHub, tienes un problema mucho más gordo que un script roto.
- Ignorar los logs. Un script que no registra nada es un script ciego. Cuando falla, no sabes dónde ni por qué.
Cualquiera de estos cinco rompe tu código sin lanzar un solo error visible. Y eso es lo peligroso.
Scripts en Excel: donde más se rompe el código sin avisar
Excel es el campo de minas perfecto. Millones de personas usan macros VBA a diario y la mayoría no sabe que están a un cambio de formato de fecha de perder meses de trabajo.
El fallo número uno en scripts de Excel: depender de la configuración regional. Una macro que lee fechas en formato DD/MM/AAAA revienta en un equipo configurado en MM/DD/AAAA. Sin error. Sin aviso. Solo datos corruptos.
Otro clásico: usar ActiveSheet en lugar de referenciar la hoja por nombre. El usuario cambia de pestaña, ejecuta la macro y machaca la hoja equivocada. He visto empresas perder inventarios enteros por esto.
Y ojo con la modernización. Excel ya permite ejecutar Python y conectar con Power Query, pero la mayoría de scripts heredados siguen en VBA sin control de versiones. Un cambio en una celda y todo el flujo se desmorona.
Scrip dividend: cuando el script no tiene nada que ver con programar
Aquí viene la trampa semántica que confunde a mucha gente. Un scrip dividend no es un script de código. Es una forma de retribución al accionista donde la empresa paga dividendos en acciones nuevas en vez de efectivo.
¿Por qué lo menciono? Porque muchos buscan «script dividend» pensando en programación y acaban en un artículo fiscal. Y al revés. La confusión es real y afecta al SEO de cualquiera que escriba sobre esto.
Fiscalmente, en España el scrip dividend tributa como una ampliación de capital liberada. No pagas impuestos al recibir las acciones, pero sí cuando las vendes, y Hacienda aplica la regla de recompra de valores homogéneos si tienes acciones antiguas. Es decir: si vendes acciones antiguas antes de dos meses, tributas por el total. Mucha gente no lo sabe y se lleva un susto en la declaración.
La ventaja para la empresa es clara: conserva liquidez y recompensa al accionista sin sacar caja. La desventaja para el inversor: dilución y dependencia del precio futuro de la acción.
Ejemplos reales de scripts que funcionan (y por qué)
Un script bien hecho no es el más corto. Es el que aguanta. Te pongo tres casos que uso yo mismo y que marcan la diferencia.
- Script de backup automático en Bash. Con comprobación de espacio en disco antes de copiar, log con timestamp y notificación si falla. Si no hay espacio, no borra el backup anterior. Eso es diseño defensivo.
- Script web para validar formularios. Valida en cliente y en servidor. Nunca confíes solo en JavaScript del navegador. El usuario puede desactivarlo o manipularlo con DevTools.
- Macro de Excel para consolidar informes. Referencia hojas por nombre, no por posición. Usa variables tipadas y maneja errores con On Error GoTo. Aburrido pero indestructible.
La diferencia entre un script que funciona y uno que rompe tu código no está en la sintaxis. Está en anticipar qué puede salir mal.
Cómo blindar tus scripts antes de que te den un disgusto
Tres reglas que aplico siempre y que te van a ahorrar noches sin dormir.
Primera: modo estricto siempre. En JavaScript, ‘use strict’ o módulos ES. Evita variables implícitas y errores tontos que se convierten en bugs graves.
Segunda: logs con contexto. No basta con console.log(‘error’). Registra la función, los parámetros de entrada y el timestamp. Cuando algo falle en producción, lo vas a agradecer.
Tercera: prueba en el entorno real. Tu script no está terminado hasta que funciona en el servidor con los datos reales y las restricciones reales. Todo lo demás es teatro.
Un script que no has probado en producción es un script que aún no sabes si funciona. Y muchas veces, el que rompe tu código sin que lo notes es precisamente el que nunca revisaste.
Así que antes de dar por bueno ese script que llevas meses usando, ábrelo. Léelo con calma. Busca variables globales, promesas sin capturar y rutas hardcodeadas. Te aseguro que encuentras al menos un error. Y arreglarlo hoy es más barato que explicarlo mañana.
