Buscar una clave en un dict de Python con diez entradas tarda lo mismo que buscarla en uno con diez millones. No es casualidad de un lenguaje rápido. El dict de Python, el HashMap de Java y el Map de JavaScript son tablas hash, y todo su diseño existe para que búsqueda, inserción y borrado funcionen en O(1) de media. La notación Big O llama a esa búsqueda “tiempo constante”. Este es el mecanismo que se lo gana. ...
Un test para place_order necesita una pasarela de pago, un cliente de SMS y una calculadora de impuestos. Conecta las versiones reales y cada ejecución del test cobra una tarjeta y manda un SMS a un número real. Un test unitario tiene que correr en milisegundos y sin red, así que las tres dependencias hay que sustituirlas por otra cosa. Ese “otra cosa” llega en cinco variantes. Cada una resuelve un problema distinto, y tratarlas como intercambiables explica por qué las discusiones de “pon un mock y ya” en code review no llegan a ningún lado. ...
<.+> contra <b>bold</b> and <i>italic</i> no encuentra <b>. Encuentra toda la cadena, desde el primer < hasta el último >. No hay ningún error. Eso es justo lo que debe hacer un cuantificador greedy, y también es el bug más común de “el regex está matcheando de más”. Una vez que sabes qué hace el motor mientras lee tu patrón, este bug y la mayoría de sus parientes dejan de ser un misterio. ...
Abre un archivo guardado en UTF-8 con una herramienta que asume otra codificación y café se convierte en café. Los bytes del disco no cambiaron. Lo que cambió es la regla usada para volver a convertirlos en caracteres, y las dos reglas no coinciden en qué significa el byte 0xC3. La mayoría de los bugs de “caracteres raros” vienen de la misma fuente: nombres de archivo rotos, formularios ilegibles, un emoji que hace fallar un insert en la base de datos, dos cadenas que se ven idénticas pero fallan al compararlas. Detrás de todos ellos hay la misma confusión entre dos cosas distintas: Unicode y UTF-8. ...
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ó. ...
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. ...
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. ...
Qué le hace realmente un decorador a tu función Quieres medir el tiempo de cada función que llama a una API externa lenta. Puedes pegar llamadas a time.perf_counter() en cada una, o escribir la medición una sola vez y aplicarla en todas partes. Un decorador es la segunda opción: es una función que toma otra función, la envuelve en un comportamiento adicional y devuelve la versión envuelta con el mismo nombre original. ...
Ejecuta 0.1 + 0.2 en una shell de Python y no obtienes 0.3. Obtienes 0.30000000000000004. Pruébalo en JavaScript, Java, Go, C o Rust y te sale la misma cola de dieciséis cifras. Cada uno de esos lenguajes hace exactamente lo que marca el estándar del hardware. Un número que necesita infinitos dígitos binarios se comprime en 64 bits, y algo tiene que ceder. Por qué 0.1 no se puede guardar de forma exacta en binario Los ordenadores guardan los números en coma flotante en base 2. En base 2, la fracción 1/10 tiene un desarrollo periódico, igual que 1/3 se repite sin fin en base 10 (0.3333...). Escrito entero, 0.1 en binario empieza así: ...