Ya conoces las piezas necesarias para una aplicación pequeña. Antes de combinarlas conviene decidir qué vas a construir y cómo reconocerás que funciona. En esta lección diseñarás un gestor de tareas de terminal para una sola persona. El resultado será un plan concreto con datos, operaciones, mensajes y criterios de aceptación que guiarán las dos lecciones siguientes.
Elegir un usuario y un problema
Nuestro usuario quiere anotar acciones breves, consultar las pendientes y marcar algunas como terminadas. Utiliza su propio ordenador y no necesita compartir la agenda con otras personas. El problema consiste en conservar una lista pequeña entre sesiones sin depender de recordar qué tareas había introducido.
La primera versión permitirá añadir, listar, completar y guardar. No tendrá cuentas, recordatorios, fechas ni sincronización. Tampoco eliminará tareas. Esta última decisión mantiene estables las posiciones mientras la aplicación está abierta y simplifica las pruebas. Podrás estudiar una función de borrado después de completar la versión inicial.
Reducir el alcance es una decisión de diseño, no una renuncia a aprender. Una aplicación pequeña que puedes ejecutar y explicar enseña más que un conjunto de funciones incompletas. Cada ampliación futura tendrá que justificar qué problema resuelve y qué comprobaciones nuevas necesita.
Definir los datos
La agenda será una lista. Cada tarea será un diccionario con dos claves: titulo y hecha. El título debe ser texto con al menos un carácter que no sea un espacio. El estado debe ser un booleano. Una nueva tarea comienza pendiente, representada por False.
Los títulos pueden repetirse porque dos acciones distintas podrían llamarse «Revisar correo». El usuario elegirá una tarea por el número que aparece en el listado. Ese número se calcula al mostrar la colección y no se guarda como identificador permanente. Si más adelante permites borrar o reordenar, deberás explicar que los números visibles pueden cambiar.
No confundas número visible con índice interno. La primera tarea se presenta como uno pero ocupa el índice cero. La función que completa tareas aceptará el número visible, comprobará que se encuentra entre uno y la longitud y después restará uno. Así concentraremos la conversión en un lugar concreto.
Describir las operaciones
Añadir recibe un título, elimina los espacios exteriores y rechaza el resultado vacío. Si acepta la entrada crea un diccionario nuevo y lo incorpora al final. Devuelve un booleano para que el menú sepa si debe mostrar un mensaje de éxito o una petición de corrección.
Listar no modifica los datos. Si la colección está vacía informa de ello. Si contiene tareas muestra número, título y estado. Completar valida el número y cambia hecha a True. Volver a completar una tarea terminada dejará el mismo estado. No cambiaremos esa operación a un interruptor que la devuelva a pendiente sin avisar.
Guardar escribe el estado completo en tareas.json. Cargar recupera el archivo al comenzar y valida su estructura. Si todavía no existe empieza con una lista vacía. Si existe pero está dañado detiene el arranque con un aviso. Esta diferencia evita borrar un archivo problemático al tratarlo como si nunca hubiera existido.
Un menú pequeño y explícito
El menú definitivo tendrá cinco acciones numeradas y una salida normal. La opción uno añade, la dos lista, la tres completa y la cuatro guarda sin cerrar. La opción cero guarda y sale. La opción cinco permite salir sin guardar únicamente después de una confirmación expresa.
Esta salida alternativa tiene una utilidad concreta: si el disco no permite guardar, el programa debe explicar el fallo y dejarte decidir qué hacer. No debe afirmar que ha guardado cuando no lo ha conseguido. Tampoco queremos que quede atrapado sin ninguna posibilidad de terminar de manera consciente.
Antes de pedir el número de una tarea mostraremos el listado. Una opción desconocida devolverá un aviso y el menú volverá a aparecer. Las entradas de menú se tratarán como texto. Solo convertiremos a entero el número visible de la tarea que se quiere completar.
Repartir el trabajo entre archivos
Utilizaremos tres archivos. logica.py contendrá agregar_tarea y completar_tarea. almacenamiento.py contendrá la validación del modelo junto con cargar y guardar. app.py se ocupará de las preguntas, los mensajes y el menú. Los tres deben permanecer en la misma carpeta.
Esta separación permite comprobar la lógica sin escribir en disco y comprobar el almacenamiento con una carpeta temporal. El menú conecta las piezas pero no contiene por sí solo todas las reglas. Si necesitas modificar cómo se muestran los estados no tendrás que cambiar el formato del archivo.
La ruta de tareas.json se definirá junto a app.py. No dependerá de la carpeta desde la que abras la terminal. El archivo de datos no es un cuarto módulo de Python y no debe ejecutarse. Se crea o se lee como consecuencia de las acciones de la aplicación.
Criterios de aceptación
Escribe comportamientos que puedas demostrar. Los siguientes serán la referencia mínima para considerar terminada la primera versión:
- Al empezar sin archivo aparece una agenda vacía.
- Añadir » Leer » conserva el título «Leer» y el estado pendiente.
- Un título vacío o compuesto solo por espacios no crea una tarea.
- Dos altas producen dos registros que pueden cambiar de forma independiente.
- Los números cero, negativos y superiores al tamaño se rechazan al completar.
- Guardar y volver a abrir conserva títulos y estados.
- Un documento dañado provoca un aviso sin reemplazarlo.
Añade también la salida sin guardar. Tras crear una tarea nueva y confirmar esa salida, el archivo debe conservar la última versión guardada. No se trata de perder información accidentalmente sino de permitir una decisión explícita que el mensaje describa con claridad.
Errores habituales
- Diseñar primero colores y ventanas sin definir operaciones y datos.
- Añadir fechas o categorías antes de tener un recorrido completo.
- Guardar la numeración visible como si fuera un identificador estable.
- Confundir un fallo de carga con una agenda vacía.
- Usar mensajes de éxito que no dependan del resultado real de la operación.
Lo que deberías recordar
- El alcance define lo que la primera versión debe hacer.
- El modelo de datos debe coincidir con las reglas de entrada y de archivo.
- Los criterios de aceptación convierten intenciones en comprobaciones.
- Cada archivo necesita una responsabilidad reconocible.
Ejercicio práctico
Completa la decimoséptima hoja antes de escribir más código. Describe al usuario, las cuatro operaciones principales y dos funciones que dejarás fuera. Dibuja el menú definitivo y el modelo de un registro pendiente.
Después redacta al menos seis criterios de aceptación con entradas concretas. Incluye el archivo inexistente, un título vacío y un número fuera de rango. Si un criterio contiene palabras vagas como «bien» o «correctamente», sustitúyelas por un resultado observable. Utilizarás este diseño para evaluar el programa real al terminar el curso.
Siguiente capítulo: Construir el gestor de tareas.
