Cerrábamos la lección anterior con tareafacil.py funcionando y una limitación evidente: todo lo que hace es imprimir texto fijo, y cambiar un dato obliga a editar el código a mano. La tentación ahora es lanzarse a aprender sintaxis para arreglarlo. Vamos a resistirla una lección más, porque falta la habilidad que de verdad separa a quien programa de quien copia código: pensar la solución antes de escribirla.

Un programador con prisa abre el editor y empieza a teclear. A las dos horas tiene código que casi funciona, no sabe por qué falla y no puede explicarle a nadie qué hace. Un programador con oficio dedica los primeros veinte minutos a papel: entiende el problema, lo descompone, escribe los pasos y los comprueba a mano. Después teclea, y teclea poco, porque ya sabe qué va a escribir.

En esta lección aprenderás qué es exactamente un algoritmo, cómo descomponer un problema, cómo expresar una solución en pseudocódigo y en diagrama de flujo, y cómo verificarla sin ordenador mediante una prueba de escritorio. Todo aplicado a dos operaciones reales de TareaFácil.

Aparecerán construcciones como «repetir» o «si...entonces»: aquí las usaremos solo como forma de pensar. Escribirlas en Python es asunto de los módulos 2 y 3.

1. Qué es un algoritmo
2. Las cinco propiedades de un algoritmo
3. Descomponer un problema en pasos y subproblemas
4. Pseudocódigo: convenciones y ejemplo
5. Diagramas de flujo
6. Prueba de escritorio: verificar sin ordenador
7. Del pseudocódigo al código Python
8. TareaFácil: registrar una tarea nueva
9. TareaFácil: qué tarea atiende Marta primero
10. Errores comunes y consejos
11. Ejercicios
12. Conclusión

Un algoritmo es una secuencia finita de pasos precisos que, partiendo de unos datos de entrada, produce un resultado en un tiempo finito.

La palabra suena técnica, pero el concepto es cotidiano: una receta de cocina, las instrucciones de montaje de una estantería y el procedimiento de la multiplicación que aprendiste en el colegio son algoritmos. Comparten lo esencial: pasos ordenados, sin ambigüedad, que terminan y producen algo.

Lo importante es esto: un algoritmo es independiente del lenguaje de programación. El mismo algoritmo para ordenar una lista se puede escribir en Python, en Java o en papel; lo que cambia es la notación, no la idea. Por eso lo que aprendas aquí te servirá aunque cambies de lenguaje diez veces.

Confundir estas cuatro cosas es el origen de mucha frustración. «No me sale el programa» suele significar en realidad «no tengo claro el algoritmo», y eso no se arregla tocando código.

No toda lista de pasos es un algoritmo. Debe cumplir cinco propiedades.

1. Preciso. Cada paso indica exactamente qué hacer, sin margen de interpretación.

• Mal: «revisa las tareas importantes».
• Bien: «para cada tarea, si su prioridad es alta y su estado es pendiente, muéstrala por pantalla».

2. Definido (determinista). Con las mismas entradas produce siempre las mismas salidas. Si ejecutas el algoritmo dos veces con los mismos datos, el resultado es idéntico.

3. Finito. Termina después de un número finito de pasos. Un algoritmo que no termina no es un algoritmo, es un bucle infinito, y es uno de los errores más habituales al empezar.

• Mal: «repite: cuenta una tarea más» (nunca acaba).
• Bien: «repite mientras queden tareas por revisar» (acaba, porque las tareas son finitas y en cada vuelta queda una menos).

4. Con entrada definida. Cero o más datos de partida, especificados con claridad. En «registrar una tarea», la entrada son el título, la descripción, el responsable y la prioridad.

5. Con salida definida. Al menos un resultado observable: un valor, un mensaje en pantalla, un fichero modificado. Un algoritmo que no produce nada observable no sirve para nada.

Aplica estas cinco preguntas a cualquier algoritmo que escribas. Detectan la mayoría de los fallos antes de que existan.

La técnica central para atacar cualquier problema se llama descomposición: partir un problema grande en problemas más pequeños hasta que cada pieza sea evidente. Se resuelve cada pieza por separado y luego se combinan.

Aplicado a TareaFácil, la petición inicial de Marta era: «quiero un programa para gestionar las tareas del estudio». Así, en bloque, es inabordable. Descompuesta:

Cada hoja del árbol es una tarea pequeña que sí sabemos abordar. «Marcar como completada» es un problema manejable; «gestionar las tareas del estudio» no lo era.

La descomposición aporta tres ventajas concretas:

• Progreso visible. Resolver una hoja del árbol lleva minutos, y ves avance. Enfrentarte al problema entero produce parálisis.
• Errores localizados. Si falla el filtrado por responsable, sabes exactamente qué pieza mirar.
• Reutilización. «Validar prioridad» sirve tanto al registrar una tarea como al modificarla. Escribirlo una vez y usarlo dos veces es la base del módulo 4.

Un criterio práctico para saber cuándo parar de descomponer: cuando puedas explicar la pieza en una frase y sepas cómo hacerla a mano. Si aún dudas, sigue partiendo.

El pseudocódigo es una forma de escribir algoritmos a medio camino entre el español y el código: lo bastante estructurado para no ser ambiguo, lo bastante libre para no pelearse con la sintaxis.

No existe un pseudocódigo oficial. Estas son las convenciones que usaremos en el curso:

Dos reglas de estilo importantes: indenta el contenido de cada bloque (facilita ver dónde empieza y acaba) y cierra siempre los bloques (FIN SI, FIN MIENTRAS).

Ejemplo completo. Algoritmo que calcula cuántas tareas pendientes tiene el estudio:

Repasemos las cinco propiedades sobre este algoritmo:

• Preciso: cada paso es inequívoco.
• Definido: la misma lista produce siempre el mismo número.
• Finito: la lista tiene un número finito de elementos y cada vuelta consume uno.
• Entrada definida: la lista de tareas con sus estados.
• Salida definida: un mensaje con el número de pendientes.

Cumple las cinco. Es un algoritmo correcto, y lo hemos verificado sin encender el ordenador.

Un diagrama de flujo representa el algoritmo gráficamente. Es especialmente útil cuando hay decisiones y caminos alternativos, porque se ven de un vistazo.

Los símbolos básicos:

Ejemplo 1: ¿la tarea es urgente? Un algoritmo con una sola decisión.

Fíjate en dos cosas: del rombo salen exactamente dos flechas etiquetadas, y ambos caminos vuelven a unirse antes del fin. Un diagrama con caminos que no acaban en FIN está incompleto.

Ejemplo 2: contar las tareas pendientes. El mismo algoritmo del apartado anterior, ahora con repetición.

El bucle se ve como lo que es: una flecha que vuelve hacia atrás, de G a D. Y ahí está la clave de la finitud: G avanza a la siguiente tarea en cada vuelta, así que en algún momento la respuesta a D será «No». Si G no existiera, el diagrama giraría para siempre. Esa flecha de retorno es el bucle infinito hecho visible, y es un buen motivo para dibujar antes de programar.

En la práctica se usan las dos: el diagrama para entender la forma general, el pseudocódigo para el detalle.

La prueba de escritorio (o trazado) consiste en ejecutar el algoritmo a mano, con datos concretos, anotando en una tabla cómo cambia cada valor paso a paso. Es la técnica más infravalorada y más rentable de todo el oficio: detecta errores de lógica en cinco minutos que en el ordenador costarían una hora.

Tracemos el algoritmo de contar pendientes con estos datos de Estudio Alba:

Y ahora la tabla de trazado. Una fila por vuelta del bucle, una columna por valor que nos interesa:

Salida: Tareas pendientes: 3. Contando a ojo en la tabla de datos: la 1, la 3 y la 4. Correcto.

Cómo hacer una prueba de escritorio bien:

1. Elige datos pequeños pero representativos. Cuatro elementos bastan; con cuarenta te cansarás y te saltarás pasos.
2. Una columna por cada valor que cambie. Si hay tres variables, tres columnas.
3. Una fila por paso o vuelta. Sin agrupar ni «ir más rápido»: el error suele estar precisamente donde uno da algo por supuesto.
4. Sé la máquina, no el autor. No hagas lo que querías escribir, haz lo que está escrito. Aquí es donde aparecen los errores.
5. Prueba también los casos límite. ¿Y si la lista está vacía? Con nuestro algoritmo, el bucle no se ejecuta ninguna vez y la salida es 0. Correcto. ¿Y si todas están completadas? También 0. Correcto.

Ese último punto merece énfasis: los casos límite son donde vive la mayoría de los errores reales. Lista vacía, un solo elemento, todos iguales, valores repetidos. Compruébalos siempre.

Cuando el algoritmo está claro y trazado, traducirlo a Python es casi mecánico. Veámoslo con un ejemplo que ya podemos escribir entero: mostrar la ficha de una tarea.

Pseudocódigo:

Python:

La correspondencia es directa: MOSTRAR se convierte en print, y el texto va entre comillas dentro de los paréntesis. INICIO y FIN no se traducen: en Python el programa empieza en la primera línea y acaba en la última.

Esta es la tabla de traducción completa que iremos completando a lo largo del curso:

De momento solo tienes la primera fila. Al terminar el módulo 3 tendrás todas, y podrás traducir a Python cualquier algoritmo que escribas en pseudocódigo. Mientras tanto, escribe pseudocódigo sin miedo: el algoritmo es lo valioso, y traducirlo será lo fácil.

Vamos a aplicar todo lo anterior al primer requisito de TareaFácil (R1 y R2 de la lista de la primera lección): registrar una tarea con sus cinco datos, validando la prioridad.

El problema. Marta quiere apuntar un encargo nuevo. Hay que pedirle título, descripción, responsable y prioridad; el estado siempre empieza como «pendiente». La prioridad solo puede ser alta, media o baja: si escribe otra cosa, hay que volver a preguntar.

Pseudocódigo:

Diagrama de flujo:

Fíjate en la flecha que vuelve de E a C: es el bucle de validación. Mientras la prioridad sea incorrecta, se vuelve a preguntar. Y es finito siempre que el usuario acabe escribiendo algo válido; si teclea disparates indefinidamente, el programa preguntará indefinidamente. Eso no es un error del algoritmo: es una decisión de diseño que conviene tomar conscientemente. Una alternativa sería permitir tres intentos y cancelar.

Prueba de escritorio. Marta registra un encargo y se equivoca al escribir la prioridad:

El paso 5 revela un problema que la prueba de escritorio ha hecho aflorar: «ALTA» en mayúsculas no coincide con «alta», porque son textos distintos. El algoritmo, tal y como está escrito, la rechazaría. ¿Es lo que queremos? Casi seguro que no: Marta escribirá en mayúsculas la mitad de las veces.

La corrección es sencilla —convertir lo introducido a minúsculas antes de comparar— y la aplicaremos en Conversión de tipos y validación. Lo relevante aquí es cómo hemos encontrado el fallo: con una tabla y un lápiz, antes de escribir una sola línea de Python. Encontrarlo más tarde, con el programa ya escrito, habría costado mucho más.

Segundo algoritmo, esta vez de decisión. Marta llega el lunes, tiene varias tareas asignadas y quiere saber por cuál empezar.

La regla de negocio, acordada con el equipo:

1. Solo cuentan las tareas pendientes: las completadas se ignoran.
2. Entre las pendientes, gana la de prioridad más alta (alta > media > baja).
3. Si hay empate de prioridad, gana la que se registró antes.

Fíjate en que estas tres reglas no las inventa el programador: se acuerdan con quien tiene el problema. Escribirlas explícitamente es parte del trabajo, y muchas veces la primera vez que el equipo se pone de acuerdo en algo que creía obvio.

Pseudocódigo:

Diagrama de flujo:

Prueba de escritorio. Las tareas de Marta, en orden de registro:

Trazado vuelta a vuelta:

Salida: Empieza por: Llamar a Panadería Solé.

Verifiquemos que es correcto según las reglas acordadas. Pendientes hay tres: Presupuesto (media), Llamar a Solé (alta) y Preparar reunión (alta). De prioridad alta hay dos, y entre ellas gana la registrada antes, que es «Llamar a Solé» (número 3 frente a número 4). Coincide con lo que produce el algoritmo.

Y los casos límite:

• Marta no tiene ninguna tarea. El bucle no se ejecuta, elegida sigue siendo NINGUNA y se muestra «No tienes tareas pendientes». Correcto.
• Todas están completadas. Todas caen por la rama que las ignora, elegida sigue NINGUNA y sale el mismo mensaje. Correcto.
• Solo una pendiente. Se asigna en su vuelta y ninguna la sustituye. Correcto.

El algoritmo aguanta los cuatro escenarios. Está listo para implementarse, y lo haremos cuando tengamos condicionales y bucles en Python.

Empezar a teclear sin haber pensado el algoritmo. Es el error más caro. Si no sabes explicar en voz alta qué pasos va a dar tu programa, no estás listo para escribirlo. Papel primero.

Pasos ambiguos. «Comprobar si la tarea es importante» no es un paso: no dice qué significa importante. «Comprobar si su prioridad es alta» sí lo es. Toda ambigüedad que dejes en el algoritmo reaparecerá como error en el programa.

Olvidar el avance dentro de un bucle. Si en cada vuelta no cambia nada que acerque al final, el bucle es infinito. En el diagrama se ve enseguida: busca qué caja hace progresar la condición del rombo. Si no la encuentras, tienes un problema.

Saltarse los casos límite. Lista vacía, un solo elemento, todos con el mismo valor, todos completados. Un algoritmo que solo funciona con el caso bonito no funciona.

Hacer la prueba de escritorio «como autor» y no «como máquina». Al trazar tiendes a ejecutar lo que querías escribir, no lo que escribiste. Es la trampa más sutil. Truco: traza un algoritmo tuyo de hace una semana, o intercámbialo con otra persona.

Dar por supuestas reglas de negocio. «Gana la de prioridad más alta» parece completo hasta que dos tareas empatan. Escribe siempre qué pasa en los empates, en los vacíos y en los datos incorrectos. Preguntarlo antes es barato; descubrirlo en producción, no.

Creer que el pseudocódigo debe ser perfecto. No es un entregable, es una herramienta de pensamiento. Táchalo, reescríbelo, usa flechas al margen. Si te ayuda a pensar, está bien escrito.

Consejo final: cuando un programa te salga mal, no empieces cambiando código a ver si acierta. Vuelve al algoritmo y hazle una prueba de escritorio. En la mayoría de los casos el error no está en la sintaxis, está en el razonamiento.

Para cada algoritmo, indica qué propiedad o propiedades incumple y corrígelo:

a)

b)

c)

Escribe el pseudocódigo y el diagrama de flujo de un algoritmo que, dada la lista de tareas del estudio y el nombre de una persona, muestre cuántas tareas pendientes tiene asignadas. Después, haz la prueba de escritorio con estos datos, buscando las de Luis:

Marta quiere poder reasignar una tarea a otra persona del equipo. Las reglas acordadas son:

• Solo se pueden reasignar tareas pendientes; una completada no se toca.
• El nuevo responsable debe ser Marta, Luis o Nuria.
• No tiene sentido reasignar a la misma persona que ya la tiene: hay que avisar.

Escribe el pseudocódigo de este algoritmo y haz una prueba de escritorio para estos tres casos: (a) reasignar a Nuria una tarea pendiente de Luis, (b) intentar reasignar una tarea completada, (c) reasignar a Luis una tarea que ya es de Luis.

Solución 1.

a) Incumple la finitud. Nada dentro del bucle reduce el número de tareas ni avanza por la lista, así que la condición nunca deja de cumplirse: se imprimiría el mensaje eternamente. Además no tiene salida útil (repite lo mismo sin informar de nada). Corrección:

b) Incumple la precisión (y, por tanto, el determinismo). «Parece urgente» no es evaluable: dos personas lo interpretarían distinto y la máquina no puede interpretarlo en absoluto. Corrección:

Se ha añadido el SINO para que haya salida en ambos casos.

c) Incumple la salida definida. Calcula correctamente el contador pero no lo muestra: el resultado se pierde al terminar. Corrección: añadir MOSTRAR "Total de tareas: " + contador antes de FIN.

Solución 2.

Pseudocódigo:

Diagrama de flujo:

Prueba de escritorio buscando las de Luis:

Salida: Luis tiene 2 tareas pendientes. Verificado a ojo: la 1 y la 4. La 3 es de Luis pero está completada, y ese es justamente el caso que comprueba que la condición doble funciona.

Solución 3.

Prueba de escritorio:

Observa el orden de las comprobaciones: primero el estado, después la validez del nombre y por último la coincidencia. Ese orden importa. Si comprobásemos primero si coincide el responsable, una tarea completada asignada a Luis que se intentase reasignar a Luis daría el mensaje equivocado. Decidir en qué orden se hacen las comprobaciones es parte del diseño del algoritmo, no un detalle.

Programar empieza lejos del teclado. En esta lección has aprendido que un algoritmo es una secuencia finita de pasos precisos que transforman una entrada en una salida, independiente del lenguaje en que se escriba, y que debe cumplir cinco propiedades: ser preciso, definido, finito, con entrada definida y con salida definida. Has visto cómo descomponer un problema grande en subproblemas manejables, cómo expresar la solución en pseudocódigo con convenciones claras y cómo dibujarla en un diagrama de flujo donde los bucles se ven como flechas que vuelven atrás. Y has practicado la técnica más rentable del oficio: la prueba de escritorio, que con una tabla y un lápiz encuentra errores que en el ordenador costarían horas —como el «ALTA» que no coincidía con «alta».

Todo ello aplicado a TareaFácil: ya tenemos diseñados, verificados y con sus casos límite comprobados los algoritmos de registrar una tarea nueva y de decidir qué tarea atiende Marta primero. No son bocetos: son especificaciones listas para implementar.

Con esto cerramos el módulo 1. Sabes qué es programar, de dónde viene el oficio, cómo se clasifican y eligen los lenguajes, tienes un entorno funcionando con tareafacil.py en tu disco y sabes diseñar un algoritmo antes de escribirlo. Es exactamente el equipaje que hace falta para empezar a escribir código de verdad.

Y ahí vamos ahora. En el módulo 2 dejamos el papel y volvemos a Python con la pieza que resuelve la limitación que arrastramos desde la lección anterior —un programa que solo imprime texto fijo—: las variables, que permiten guardar datos y trabajar con ellos. Empezaremos por Variables y tipos de datos, donde por fin el título, el responsable y la prioridad de una tarea dejarán de estar escritos a mano dentro de un print y pasarán a ser información que el programa maneja.