Software Development

¿Qué Es una Closure en JavaScript? 1 2 3 4 5 6 7 8 9 10 11 12 function makeCounter() { let count = 0; return function () { count += 1; return count; }; } const counter = makeCounter(); console.log(counter()); // 1 console.log(counter()); // 2 console.log(counter()); // 3 makeCounter se ejecuta una vez, devuelve una función, y ahí termina: su stack frame ya no existe. Aun así, cada llamada a counter() sigue leyendo y actualizando count, una variable declarada dentro de una función que ya terminó. count no vuelve a 0, y no se copia. Es la misma variable, todavía viva, tres llamadas después. ...

Un test escrito después del código tiende a comprobar lo que el código hace, no lo que debía hacer. El desarrollo guiado por pruebas (TDD) resuelve esto invirtiendo el orden: escribes el test, lo ves fallar, y luego escribes el código mínimo que lo hace pasar. El test existe antes que el código que examina, así que no puede limitarse a confirmar en silencio lo que ese código termine devolviendo. Kent Beck formalizó este ciclo como red, green, refactor en su libro de 2002 Test-Driven Development: By Example. El nombre se quedó. ...

Cierra la sesión de un usuario en una app basada en sesiones y el servidor lo olvida en la siguiente petición. Cierra la sesión en una app basada en JWT y, a menos que hayas montado un mecanismo extra, el token que tiene en la mano sigue siendo válido hasta que expira. Esa diferencia es la decisión real detrás de “JWT vs sesión”. El resto se deriva de ahí. Qué guarda realmente una sesión Una sesión mantiene el estado del usuario en el servidor y al navegador solo le pasa una clave de búsqueda. ...

Envuelve una llamada fetch() en un try/catch, apunta a un endpoint que responde con un 404, y el bloque catch nunca se ejecuta. La promesa se resuelve. res.json() analiza el cuerpo que haya devuelto el servidor, muchas veces un payload de error como {"error": "user not found"}, y el resto de la función lo trata como el registro que pedía. Sin excepción, sin aviso en consola. El dato incorrecto sigue viajando hasta que algo más se rompe con él. ...

Una función que se llama a sí misma tiene una profundidad máxima, y es más pequeña de lo que la mayoría espera: 1.000 llamadas en CPython por defecto, entre 10.000 y 15.000 en Node y en los motores de los navegadores, según cuánto pese cada frame. Pasarse de ese límite no hace que el programa vaya más lento: lo hace fallar. Python lanza RecursionError: maximum recursion depth exceeded; JavaScript lanza RangeError: Maximum call stack size exceeded. ...

Estás montando un dashboard: un header, un sidebar, un área de contenido principal y un footer. Recurres a Flexbox porque es la herramienta de layout que conoces, y veinte minutos después tienes tres contenedores display: flex anidados, un sidebar que no mantiene su ancho sin un número mágico, y un footer que flota a mitad de página cuando el contenido es corto. Nada de eso es un bug de Flexbox. Estás usando una herramienta unidimensional para un problema bidimensional. ...

Pon go delante de una llamada a función y esa función se ejecuta en concurrencia con el resto del programa, gestionada por el runtime de Go en lugar del sistema operativo. Lanzarla es la parte fácil. La difícil es conseguir que dos goroutines se pasen un resultado sin pisarse el estado mutuamente, y de eso se encargan los channels. ¿Qué es una goroutine? Una goroutine es una función que corre de forma independiente de la que la lanzó, gestionada por el runtime de Go y no por el sistema operativo. Un thread del sistema operativo reserva un megabyte o más de stack y le cuesta al kernel tiempo real planificarlo. Una goroutine arranca con un stack de unos 2KB que crece según lo necesita, y el runtime multiplexa muchas goroutines sobre un puñado de threads del sistema operativo. Lanzar miles de ellas es normal. ...

Una clase que guarda un usuario en la base de datos, le manda un correo de bienvenida y da formato a un recibo: basta un cambio para romper dos funcionalidades que no tienen nada que ver entre sí. Tocas la plantilla del correo y arriesgas la escritura en la base de datos. Tocas el diseño del recibo y arriesgas el correo. SOLID son cinco reglas que atacan ese tipo de enredo desde ángulos distintos, y comparten una idea: una clase debe cambiar por un solo motivo, y el resto del código debe depender de lo que algo promete hacer, no de cómo lo hace. ...

Dos peticiones llegan al mismo endpoint “retirar 100€” con medio milisegundo de diferencia. La cuenta tiene 150€. Ambas peticiones leen ese saldo, ambas ven fondos suficientes, ambas aprueban, ambas restan 100€. La cuenta acaba en -50€, y ninguna rama del código debería haber permitido eso. Eso es una race condition: el resultado depende de qué operación termina primero, y “primero” nunca fue algo que el código decidiera. ¿Qué causa una race condition? Hacen falta dos ingredientes a la vez: estado mutable compartido, y más de un camino de ejecución que lo toca sin coordinarse. Los caminos pueden ser threads, tareas async, procesos, o dos servidores accediendo a la misma fila de base de datos. Quita cualquiera de los dos ingredientes y el bug desaparece. Un solo thread no puede competir contra sí mismo, y un estado inmutable no puede corromperse por leerse dos veces. ...

Un buscador que lanza una petición en cada pulsación manda cinco peticiones para “redis”, y cuatro llegan obsoletas antes de que vuelva la respuesta. Un handler de scroll que recalcula el layout se ejecuta cientos de veces por segundo y hace que la página se trabe. El mismo problema en los dos casos: el evento del DOM se dispara mucho más a menudo de lo que el handler necesita ejecutarse. Debounce y throttle lo resuelven de dos formas distintas. ...