Loading
Enroll to access all the lessons in this course.
Lesson 1 of 29· Empieza aquí: leer código como quien revisa
Lee esta función. Corre sin errores, tiene su docstring, su nombre es claro y pasaría cualquier revisión de tres segundos:
¿La aprobarías?
def aplicar_descuento(precio, porcentaje):
"""Devuelve el precio con un descuento porcentual aplicado."""
return precio - (precio * porcentaje / 100)
print(aplicar_descuento(100, 10)) # 90.0 parece correcto
print(aplicar_descuento(100, 110)) # -10.0 el cliente cobra por comprar
print(aplicar_descuento(100, -20)) # 120.0 el descuento sube el precioNo hay error de sintaxis. No hay excepción. No hay nada rojo en la pantalla. Hay un precio negativo entrando a la base de datos de una tienda real.
Ese es el fallo caro: no el código que se rompe, sino el código que corre y está sutilmente mal. El intérprete atrapa gratis los errores de sintaxis; los errores de razonamiento solo los atrapa alguien que lee con criterio. Ese alguien vas a ser tú al terminar este curso.
Piensa en tu último día de trabajo con código. ¿Qué proporción escribiste tú, línea por línea, desde cero?
La realidad de casi cualquier persona que programa hoy:
Escribir código dejó de ser el cuello de botella. Decidir si un pedazo de código es correcto sí lo es. Y esa decisión es una habilidad entrenable, con método, no un talento místico que aparece con los años.
Nota importante: este curso vale exactamente igual si nunca usas una IA. Todo lo que vas a practicar —predecir salidas, aplicar una rúbrica, cazar off-by-one, escribir el test que atrapa el bug, depurar con método— es lectura y revisión de código a secas, la misma que necesitas para revisar el PR de un compañero o para entender un módulo que heredaste. Lo que sí haremos es aprovechar que el código generado por IA falla de forma muy característica: corre, se ve idiomático, y está mal en un detalle. Es material de práctica perfecto.
Revisar no es "mirar el código hasta que te parezca bien". Es un ciclo corto y repetible:
El paso que casi nadie hace es el segundo. Predecir antes de ejecutar es lo que convierte leer código en aprender: si tu predicción falla, acabas de encontrar exactamente dónde tu modelo mental del lenguaje está roto. Si acierta, la lectura te costó diez segundos y ya no necesitas ejecutar nada.
Y el último paso es el que separa "creo que lo arreglé" de "lo arreglé": un bug no está corregido hasta que existe un test que fallaba antes y pasa ahora.
Cuando alguien te pone una función delante, no improvises. Recórrela por estos cuatro ejes, siempre en este orden:
| Eje | La pregunta que te haces | Ejemplo de hallazgo |
|---|---|---|
| 1. Corrección | ¿Hace lo que dice que hace, en el caso normal? | La media divide entre len(x)-1 |
| 2. Casos borde | ¿Y con lista vacía, un solo elemento, negativos, None, duplicados, el primero y el último? | aplicar_descuento(100, 110) devuelve un precio negativo |
| 3. Claridad | ¿Se entiende sin adivinar? ¿Los nombres mienten? ¿El docstring corresponde al código? | La función se llama validar pero además guarda en disco |
| 4. Complejidad accidental | ¿Hay complejidad que el problema no pedía? | Tres bucles anidados donde bastaba un dict |
El orden importa: un código bellísimo que devuelve el número equivocado sigue estando mal, así que la corrección va primero. Y fíjate en que el eje 2 es donde vive la mayoría de los bugs de este curso —el caso normal casi siempre funciona; los bordes son los que se caen.
Módulo a módulo iremos llenando esta rúbrica con un catálogo de fallos plausibles concretos: off-by-one, rangos mal cerrados (< vs <=), argumentos por defecto mutables, comparación de flotantes, tipos que se corrompen en silencio, APIs que no existen y tests que pasan por casualidad.
Cada tema sigue el mismo formato:
Todo el código corre en tu navegador; no necesitas instalar nada para empezar. Al final del curso, una lección corta te lleva a montarlo en tu propia máquina con pytest de verdad, que es donde harás esto en el trabajo.
Qué necesitas: Python básico —funciones, listas, diccionarios, bucles, if. Nada más. Si además ya manejas clases y anotaciones de tipo, vas a exprimir mejor un par de ejemplos, pero en ningún momento son obligatorios. Y si algo de sintaxis se te escapa, lo recordamos en una línea cuando aparezca.
Son unas 6 horas de trabajo real, y salen mejor en sesiones cortas: revisar código cansa más que escribirlo.
Antes de irte, estrena el músculo. Lee la celda de abajo sin ejecutarla y escribe tu predicción en prediccion. La celda comparará tu respuesta con el resultado real.
Lee la función top_n sin ejecutar la celda y decide qué devuelve top_n(datos, 3). Sustituye la lista vacía de prediccion por tu respuesta (una lista literal de tres enteros) y ejecuta. La celda debe imprimir True seguido del resultado real.
def top_n(valores, n):
"""Devuelve los n valores mas grandes, de mayor a menor."""
return sorted(valores, reverse=True)[:n]
datos = [4, 42, 15, 16, 23, 8]
# TODO: sin ejecutar nada, escribe aqui la lista que crees que devuelve top_n(datos, 3)
prediccion = []
real = top_n(datos, 3)
print(prediccion == real, real)Si tu predicción falló en la celda de arriba, felicitaciones: acabas de ver el curso entero en miniatura. Si acertó, mejor todavía —vas a acertar mucho más seguido dentro de seis horas.
Ahora sí, a cazar. En la siguiente lección te ponemos una función de facturación de aspecto perfectamente normal, con su test verde y todo, y en tres minutos vas a encontrar y corregir el bug que esconde. No hace falta que sepas nada más de lo que ya sabes: solo leer con la sospecha encendida.
Free