En la lección anterior aprendiste a elegir estructura con criterio; en esta vamos a mirar atrás con calma. Repasaremos el curso completo contándolo como lo que realmente ha sido: la historia de TaskFlow, una aplicación que empezó siendo un simple diccionario de Python y terminó con tablero, deshacer, notificaciones, índices, jerarquías y un planificador de dependencias. Ver el camino entero de una vez fija el mapa mental mejor que cualquier lista de definiciones, y el test de autoevaluación final te dirá con honestidad qué llevas bien atado y qué conviene repasar antes de los proyectos.

1. La evolución de TaskFlow, módulo a módulo
2. Tabla-chuleta: todo lo que hemos construido
3. Los cinco conceptos transversales
4. Qué sabes hacer ahora que no sabías al empezar
5. Autoevaluación tipo test

TaskFlow nació como un dict humilde: {"id": 1, "titulo": "...", "prioridad": 2, "estado": "pendiente"}. Antes de construir nada aprendimos a pensar: la diferencia entre el contrato de un TDA y su implementación, la notación Big O de O(1) a O(n²), la tabla de costes de list/dict/set, y cómo medir de verdad con timeit. También miramos la memoria de frente: un array es contigüidad pura (base + i × tamaño, y de ahí el acceso O(1)), la list de Python es un array dinámico, y insert(0)/pop(0) esconden un O(n) que perseguiríamos durante todo el curso.

Primer problema real: insertar y borrar tareas del tablero sin pagar desplazamientos. Con Nodo y ListaEnlazada construimos el tablero de TaskFlow y aceptamos el trato de las listas enlazadas: inserción O(1) en cabeza a cambio de acceso O(n) por posición. NodoDoble y ListaDoblementeEnlazada dieron el HistorialTareas navegable en ambos sentidos, y la ListaCircular el RepartidorTareas round-robin. De propina, los clásicos: invertir la lista, detectar ciclos con Floyd (liebre y tortuga), fusionar ordenadas e insertar_ordenado.

"Ctrl+Z" es la operación estrella de cualquier editor, y su estructura es la pila: lo último que hiciste es lo primero que se deshace. Sobre Pila y PilaEnlazada montamos el HistorialAcciones y el GestorDeshacerRehacer con dos pilas (deshacer empuja en rehacer, y viceversa). Vimos que la pila también valida (filtro_balanceado), calcula (evaluar_postfija, infija_a_postfija), recuerda extremos (PilaConMinimo) y sostiene la propia ejecución del programa: la pila de llamadas explica la recursión, el RecursionError y cómo convertir recursión en iteración con una pila explícita.

Las notificaciones exigían justicia FIFO: Cola sobre ListaEnlazada dio la ColaNotificaciones, y por el camino demostramos que dos pilas hacen una cola (ColaConDosPilas). La ColaCircular (ring buffer) resolvió el RegistroEventos con memoria fija. Cuando "por orden de llegada" dejó de bastar, llegaron las colas de prioridad: de la versión ingenua a heapq con tuplas (prioridad, contador, tarea) en la BandejaUrgencias. Y collections.deque demostró ser la navaja suiza de los extremos: HistorialConLimite con maxlen, VentanaProductividad de media móvil y el deque monótono.

Buscar una tarea por id recorriendo listas era O(n); la magia O(1) del dict dejó de ser magia cuando construimos una tabla hash desde cero: TablaHashIngenua, hash polinómico, colisiones por encadenamiento, factor de carga 0.75 y rehashing en TablaHash. En la práctica: claves hashables, defaultdict, Counter, el índice invertido etiqueta→ids del BuscadorEtiquetas, memoización y two-sum. Y el límite honesto que abrió el siguiente módulo: el hash no conoce el orden ni entiende de rangos.

Los proyectos contienen tareas que contienen subtareas: jerarquía pura. NodoArbol modeló el árbol general y presupuestar mostró el poder del postorden (los hijos antes que el padre). Con NodoBinario llegaron los tipos de árbol, la representación en array (hijos en 2i+1/2i+2) y los cuatro recorridos, también iterativos con pila. El ArbolBusqueda (ABB) resolvió por fin "prioridad entre 1 y 3" con rango, el ArbolAVL garantizó O(log n) con rotaciones, los árboles B/B+ explicaron los índices de las bases de datos, y el Monticulo propio (flotar/hundir) reconstruyó heapq por dentro para la BandejaUrgencias 2.0. Clásicos: es_abb, reconstruir, top_k.

"La tarea B no puede empezar hasta acabar la A" no es jerarquía: es un grafo. La clase Grafo (lista de adyacencia como dict de dicts, con la convención "arista A→B = B depende de A") modeló el DAG de TaskFlow. BFS con deque, DFS recursivo e iterativo, hay_ciclo con colores blanco/gris/negro y el orden_topologico de Kahn ordenaron el trabajo; componentes_conexas agrupó; dijkstra, bellman_ford y la mención a Floyd-Warshall midieron caminos; prim, kruskal y UnionFind tejieron redes mínimas. El broche: el planificador completo con niveles paralelos y ruta_critica, más sugerir_colaboradores, pagerank y los grafos implícitos en rejilla.

Este módulo: el método de las siete preguntas, el árbol de decisión, la gran tabla, y los proyectos que vienen.

Tu índice de referencia rápida. Si algún nombre no te evoca inmediatamente su idea, esa es la lección a repasar.

Más importantes que cualquier estructura concreta, porque son los que seguirás usando cuando aparezcan estructuras que este curso no cubre:

1. TDA frente a implementación. La pila es un contrato (push/pop/peek); list, PilaEnlazada o un deque son formas de cumplirlo. Programa contra el contrato y podrás cambiar la implementación sin tocar el resto del código.
2. Big O como idioma. No es matemática decorativa: es la forma de predecir si un código que funciona con 100 elementos sobrevivirá a 100 000. La diferencia entre in sobre list (O(n)) y sobre set (O(1)) decide si tu bucle es lineal o cuadrático.
3. Recursión ↔ iteración. Toda recursión es una pila implícita; toda recursión se puede reescribir con una pila explícita (y a veces conviene, recuerda RecursionError). Recorridos de árboles y DFS son el mismo patrón con dos trajes.
4. Estructuras que construyen estructuras. La cola sobre lista enlazada, la cola con dos pilas, la pila con mínimo, el montículo sobre array, el grafo sobre dict de dicts, la caché LRU con dict + lista doble... Componer es la habilidad; memorizar, solo el atajo.
5. Medir en vez de suponer. timeit fue la primera herramienta del curso y debe ser la última palabra en cualquier discusión de rendimiento. La teoría orienta; los datos reales deciden.

Lista honesta: todo esto lo has hecho, no solo leído.

• Leer y escribir análisis Big O de tu propio código, y verificar la teoría con timeit.
• Implementar desde cero, en Python, listas enlazadas (simple, doble, circular), pilas, colas, ring buffers, tablas hash con colisiones y rehashing, ABB, AVL, montículos y grafos.
• Elegir entre list, dict, set, deque y heapq sabiendo qué hay debajo y qué cuesta cada operación.
• Reconocer patrones: LIFO → pila, FIFO → cola, "el más urgente" → montículo, clave exacta → hash, rangos → árbol, dependencias → grafo.
• Aplicar los algoritmos clásicos: Floyd, recorridos de árboles, BFS/DFS, detección de ciclos, orden topológico, Dijkstra, Bellman-Ford, Prim, Kruskal.
• Combinar estructuras coordinadas para cumplir varios requisitos de coste a la vez.
• Y lo que aún no sabes (ordenación en profundidad, programación dinámica, tries...): lo tienes localizado, y la siguiente lección te da el mapa para llegar.

• Confundir "me suena" con "lo sé". El test de abajo es útil solo si lo haces sin mirar; el repaso pasivo produce una falsa sensación de dominio.
• Repasar estructuras como fichas aisladas. Repasa problemas: "¿cómo haría el deshacer?", "¿cómo detectaría el ciclo?". La estructura debe venir a ti desde el problema, no al revés.
• Saltarse los porqués. Saber que el dict es O(1) sin recordar el hash polinómico y el rehashing es conocimiento frágil: se cae en la primera pregunta de seguimiento de una entrevista.
• No reimplementar de memoria. Antes de los proyectos, prueba a reescribir sin mirar una Pila, una ColaCircular y el BFS. Donde te atasques, ahí está tu hueco real.

Autoevaluación tipo test. Responde sin consultar las lecciones y luego contrasta con las soluciones razonadas.

1. En una list de Python con 1 000 000 de elementos, ¿cuál de estas operaciones es la más cara? (a) lista[500000] (b) lista.append(x) (c) lista.insert(0, x) (d) lista.pop()
2. El GestorDeshacerRehacer usa dos pilas. Al ejecutar "deshacer", ¿qué ocurre exactamente?
3. ¿Por qué la BandejaUrgencias encola tuplas (prioridad, contador, tarea) y no (prioridad, tarea)?
4. Un compañero guarda los ids de tareas completadas en una list y comprueba id in completadas dentro de un bucle sobre 50 000 tareas. ¿Cuál es el coste total y cómo lo arreglas?
5. ¿Qué estructura responde "dame todas las tareas con prioridad entre 1 y 3" en O(log n + k), y por qué un dict no puede?
6. Insertas en un ABB las claves 1, 2, 3, 4, 5, en ese orden. ¿Qué forma tiene el árbol y qué coste tiene ahora buscar el 5? ¿Qué estructura lo evita?
7. ¿Qué recorrido usó presupuestar para sumar el coste de proyectos → tareas → subtareas, y por qué precisamente ese?
8. En el DAG de dependencias de TaskFlow, ¿qué algoritmo te da un orden válido de ejecución y qué señal te avisa de que no existe tal orden?
9. ¿Verdadero o falso? "Un montículo mantiene todos sus elementos completamente ordenados."
10. ¿Qué dos estructuras combinaba la caché de "modo repaso" (ejercicio 3 de la lección anterior) y qué aporta cada una?

1. (c) insert(0, x) es O(n): desplaza el millón de elementos una posición. (a) es O(1) por contigüidad (base + i × tamaño); (b) y (d) son O(1) (amortizado en el append) porque tocan solo el final.
2. Se hace pop de la pila de deshacer (la acción más reciente), se revierte su efecto y esa acción se hace push en la pila de rehacer. Si después el usuario ejecuta una acción nueva, la pila de rehacer se vacía: la historia alternativa deja de ser válida.
3. Dos razones: el contador desempata prioridades iguales garantizando orden de llegada (FIFO dentro de la misma prioridad) y, además, evita que heapq intente comparar los dicts de tarea entre sí (los dict no son comparables y lanzaría TypeError).
4. in sobre list es O(n); dentro del bucle, O(n·m) — con 50 000 tareas, del orden de miles de millones de comparaciones. Conviertes completadas en set una sola vez (O(m)) y cada consulta pasa a O(1): el total queda en O(n + m).
5. Un ABB/AVL (o una lista ordenada con bisect): desciendes hasta el arranque del rango en O(log n) y recorres en inorden los k resultados. El dict no puede porque la función hash dispersa a propósito: destruye toda relación de orden entre claves para lograr el O(1) por clave exacta.
6. Degenera en una "lista" inclinada a la derecha: cada clave es mayor que la anterior, así que todos cuelgan del hijo derecho. Buscar el 5 cuesta O(n). Lo evita el AVL, que rota al detectar desequilibrio y garantiza altura O(log n) llegue como llegue la entrada.
7. Postorden: procesa los hijos antes que el padre, de modo que cuando toca calcular el presupuesto de un nodo, los presupuestos de todos sus subárboles ya están calculados y basta sumarlos.
8. El orden topológico (Kahn: ir extrayendo nodos con grado de entrada 0). Si el algoritmo termina sin haber procesado todos los vértices —o si el DFS de colores encuentra una arista hacia un nodo gris—, hay un ciclo de dependencias y no existe orden válido.
9. Falso. El montículo solo garantiza la propiedad de montículo: cada padre ≤ sus hijos (en un min-heap). El mínimo está en la raíz, pero los hermanos no guardan orden entre sí; por eso insertar y extraer son O(log n) y no O(n) — es un orden "suficiente", no total.
10. Un dict id→nodo (localizar en O(1)) y una lista doblemente enlazada con el orden de uso (mover un nodo a cabeza y expulsar por la cola en O(1)). El dict no sabe de orden; la lista no sabe buscar: juntas, todas las operaciones son O(1).

Interpretación: 9-10 aciertos, listo para los proyectos; 6-8, repasa las lecciones de las preguntas falladas; menos de 6, vuelve a los ejercicios de los módulos flojos antes de seguir — los proyectos finales asumen todo esto.

TaskFlow ha pasado de un dict suelto a un sistema con siete familias de estructuras trabajando coordinadas, y tú has pasado de usar list "porque sí" a justificar cada elección con operaciones y costes. El mapa está completo: los cimientos (módulo 1), las estructuras lineales (2-4), los índices (5), las jerarquías (6), las redes (7) y el criterio (8). En la siguiente lección te dejo la biblioteca: los recursos con los que seguir creciendo por tu cuenta cuando este curso termine.