Ya tienes las tres herramientas: sabes definir y llamar funciones (04-01), sabes darles parámetros y hacer que devuelvan valores (04-02), y sabes de qué deben depender para ser piezas autónomas (04-03). Lo que falta es el criterio: ante un programa de cien líneas escritas de un tirón, ¿por dónde se corta? ¿Cuántas funciones? ¿De qué tamaño? ¿Qué va dentro de cada una?

Esa pregunta no tiene una respuesta mecánica, pero sí tiene criterios sólidos y comprobables, y esta lección los recorre uno a uno. Al final los aplicaremos al caso que llevamos arrastrando desde el módulo 3: convertir el muro monolítico de tareafacil.py v0.6 en la versión 0.7, un programa organizado en funciones con un main() que se lee en veinte segundos. Lo que vamos a hacer tiene nombre propio: refactorizar, es decir, reorganizar el código sin cambiar lo que hace. Al terminar, TareaFácil se comportará exactamente igual de cara al usuario; lo que cambia es todo lo demás, la facilidad para entenderlo, corregirlo y ampliarlo.

1. Una función, una responsabilidad
2. Tamaño y nivel de abstracción
3. Diseño descendente: escribir el main() primero
4. El árbol de llamadas
5. Separar entrada/salida de lógica
6. Nombres que describen el efecto
7. DRY y el exceso contrario
8. El bloque if __name__ == "__main__":
9. TareaFácil v0.7: el refactor completo
10. Errores comunes y consejos
11. Ejercicios
12. Conclusión

El criterio principal es este: una función debe hacer una sola cosa y hacerla entera. La prueba práctica consiste en describirla en una frase corta, sin conjunciones. Si necesitas una «y», tienes dos funciones.

La ventaja de respetarlo no es estética, es económica. Una función con una sola responsabilidad tiene una sola razón para cambiar. El día que Estudio Alba decida aceptar días con decimales, tocas pedir_entero y nada más. Si esa misma función también pintara la ficha, cambiar el formato de la ficha te obligaría a tocar código de validación, con el riesgo de romperlo sin darte cuenta.

De la regla anterior se sigue un tamaño típico: entre tres y veinte líneas. No es una ley, es una consecuencia: una función que ocupa sesenta líneas casi siempre está haciendo varias cosas. Y hay una señal muy fiable de que se ha pasado: si para explicársela a alguien tienes que decir «primero hace esto, luego esto otro, y al final aquello», esos tres pasos quieren ser tres funciones. El segundo criterio, más sutil pero muy potente, es el nivel de abstracción homogéneo: dentro de una misma función, todas las líneas deberían contar la historia a la misma altura. Compara estas dos versiones de lo mismo:

La segunda se lee como un resumen de lo que ocurre; la primera obliga a leer código de formateo para enterarte de la trama. La regla mnemotécnica: una función debe leerse como un índice, no como una novela.

El diseño descendente (top-down) consiste en escribir primero el programa principal como si las funciones que necesitas ya existieran, y solo después implementarlas. Es contraintuitivo y funciona sorprendentemente bien, porque te obliga a decidir qué necesitas antes de perderte en el cómo:

Ninguna de esas funciones existe todavía, y sin embargo ya has tomado las decisiones importantes: cuántas piezas hay, cómo se llaman y qué recibe cada una. Ese esbozo es a la vez un plan de trabajo y una lista de tareas. El truco práctico para no bloquearte es rellenar los huecos con funciones vacías que solo tengan un pass o un print provisional. Así el programa se ejecuta desde el primer minuto y puedes ir sustituyendo esos esqueletos por implementaciones reales de una en una, comprobando después de cada paso. Es mucho mejor que escribirlo todo y ejecutarlo por primera vez al final, cuando cualquier error puede estar en cualquier sitio.

Al descomponer aparece una estructura en capas: el main() llama a funciones de acción y estas llaman a funciones auxiliares. Dibujarla ayuda a detectar desequilibrios:

Tres cosas que este árbol te dice de un vistazo. Primero, que hay dos niveles claros: acciones arriba y utilidades abajo. Segundo, que pedir_opcion la usan tres funciones distintas: es la pieza más reutilizada del programa, y eso confirma que valía la pena extraerla. Y tercero, que ninguna rama baja más de tres niveles, señal de que el programa no está sobre-fragmentado.

Esta es la regla que más mejora un programa por línea de esfuerzo: las funciones que calculan no imprimen ni preguntan. El trabajo se reparte en tres familias:

¿Por qué importa tanto? Porque una función de lógica pura es comprobable: le das unas entradas, miras el valor devuelto y sabes si está bien, sin teclear nada ni mirar la pantalla. clasificar_urgencia("alta", 2) debe devolver "CRITICA", y eso se puede verificar mil veces en un segundo; si esa función imprimiera en lugar de devolver, la única forma de comprobarla sería ejecutar la aplicación y leer con los ojos. Esta idea es la base de las pruebas automatizadas. Hay además un beneficio más inmediato: si mañana TareaFácil pasa a tener interfaz gráfica o a generar un informe en un fichero, toda la lógica se salva y solo cambian las funciones de entrada y salida.

El nombre de una función es un contrato con quien la lee, y hay cuatro señales fáciles de aplicar. La primera son los prefijos: mostrar_* imprime y no devuelve nada útil, obtener_* o calcular_* devuelven y no imprimen, pedir_* pregunta al usuario; cumplirlos hace que el lector acierte sin abrir la función. La segunda: los nombres con «y» delatan dos responsabilidades, así que validar_y_guardar() no es un nombre largo sino un diagnóstico —pártela en validar() y guardar(). La tercera: evita nombres genéricos como procesar, gestionar o datos, porque si no encuentras un nombre concreto suele ser que la función no tiene un propósito concreto. Y la cuarta: el nombre debe advertir de los efectos; una función llamada calcular_total que además pone a cero un contador está mintiendo, y quien la use se llevará una sorpresa desagradable.

DRY —Don't Repeat Yourself, no te repitas— es el principio que dice que cada pieza de conocimiento debe estar en un solo lugar del programa. Es lo que llevamos aplicando desde 04-01. La forma práctica de aplicarlo es preguntarse, ante dos trozos parecidos, en qué se diferencian. Si la diferencia es un valor —un mensaje, un rango, un catálogo—, ese valor quiere ser un parámetro y los dos trozos quieren ser una función; si la diferencia es estructural, quizá no sean lo mismo y forzar la unión los empeore a los dos. Porque también existe el exceso contrario, la sobre-fragmentación: partir en funciones diminutas que no aportan nada, como un def sumar_uno(n): return n + 1 o un def es_cero(n): return n == 0. Estas funciones alargan el programa y obligan al lector a saltar de sitio en sitio para descubrir que hacían lo obvio. Una función merece existir si se cumple al menos una de estas tres condiciones: se usa más de una vez, su nombre explica algo que el código no dice por sí solo, o oculta una complejidad que ensuciaría a quien la llama. clasificar_urgencia cumple la segunda; pedir_entero cumple las tres; sumar_uno no cumple ninguna.

Habrás visto estas dos líneas al final de casi cualquier programa Python, después de todas las definiciones:

__name__ es una variable que Python crea automáticamente en cada fichero. Cuando el fichero se ejecuta directamente (python tareafacil.py), su __name__ vale "__main__" y la condición se cumple, así que main() arranca. Cuando el fichero se importa desde otro para aprovechar sus funciones, __name__ vale en cambio el nombre del fichero ("tareafacil"), la condición es falsa y la aplicación no se lanza sola. Eso es lo que quieres: poder reutilizar clasificar_urgencia desde otro programa sin que se te abra el menú por sorpresa. La teoría completa de la importación es Módulos, paquetes e importaciones; por ahora adopta la forma, que es siempre la misma: define main(), ponla al final junto a las demás definiciones, y cierra el fichero con ese bloque de dos líneas.

Recordemos el punto de partida. La v0.6 era un único bloque de casi cien líneas seguidas, con esta forma:

Y aquí está la v0.7 completa, con las funciones agrupadas por familias:

Lo que ha cambiado, punto por punto:

• El bucle principal cabe en veinte líneas y se lee como una tabla de decisiones. Ya no hay ni un input ni un print de formateo dentro: solo llamadas a funciones con nombre.
• if not hay_tarea: estaba escrito tres veces; ahora está una. El truco es el elif not hay_tarea: colocado después de las opciones 5 y 1 —las dos únicas que funcionan sin tarea registrada— y antes de las opciones 2, 3 y 4. Si no hay tarea, la cadena de elif se detiene ahí y ninguna de las tres se ejecuta.
• Las cuatro validaciones duplicadas son ahora tres funciones, y pedir_opcion sirve para el menú, para el responsable y para la prioridad. confirmar(mensaje) unifica además las tres confirmaciones y encierra en un solo sitio la decisión de que solo "s" confirma.
• registrar_tarea() devuelve cuatro valores que se desempaquetan de golpe (04-02), y cambiar_prioridad y marcar_completada devuelven el nuevo valor en vez de modificarlo por su cuenta: ninguna función toca el estado que no le pertenece, como manda 04-03.

Sí: el fichero tiene más líneas que antes. Es lo normal en un refactor y no es mal negocio, porque lo que se mide no es cuánto ocupa el programa sino cuánto hay que leer para entender un trozo: antes, para saber qué hacía la opción 3, había que leer las setenta y cinco líneas del bucle; ahora se leen cuatro. Queda, eso sí, un cabo suelto, y es grande. Mira la cabecera de mostrar_ficha: cinco parámetros que son siempre los mismos cinco, viajando juntos de función en función. Y mira el principio de main(): seis variables sueltas declaradas una detrás de otra. Esas seis variables son una sola cosa —una tarea— que todavía no tiene forma de ser una sola cosa en nuestro código. Cuando conozcas las tuplas y estructuras anidadas podrás agruparlas, y cuando llegues a las clases podrás darles nombre propio y comportamiento. Hasta entonces, viajan de la mano.

Extraer funciones que siguen dependiendo de globales. Mover diez líneas a un def no es descomponer si esas líneas siguen leyendo y escribiendo variables del programa principal. Comprueba cada función con la prueba del recorte de 04-03. Y las funciones que hacen dos cosas suelen delatarse en el nombre (validar_y_guardar) o al describirlas: pártelas, aunque cada mitad quede muy corta.

Mezclar niveles de abstracción. Un main() con un print("=" * 46) en medio de llamadas de alto nivel: ese print pertenece a mostrar_menu. El defecto contrario es sobre-fragmentar: veinte funciones de dos líneas usadas una sola vez son tan difíciles de leer como un bloque de doscientas. Refactorizar y añadir funcionalidad a la vez. Es la receta para no saber qué ha roto qué. Primero reorganiza dejando el comportamiento idéntico, comprueba que todo sigue igual, y solo entonces añade lo nuevo. Y no olvides el if __name__ == "__main__":, ni dejes código suelto en el margen izquierdo entre las definiciones: se ejecutará en cuanto alguien importe el fichero.

Consejo: refactoriza en pasos pequeños y ejecuta después de cada uno. Extrae una función, ejecuta, comprueba; si algo falla, sabes exactamente qué paso lo causó. Y escribe el main() como te gustaría que fuera: si al leerlo entiendes el programa sin abrir ninguna otra función, la descomposición es buena, y de paso tienes la mejor documentación que tendrá tu programa.

Este programa funciona pero está escrito de un tirón. Identifica sus responsabilidades, propón los nombres de las funciones en que lo partirías —indicando parámetros y qué devuelve cada una— y escribe el main() resultante.

Un compañero ha partido su programa en estas tres funciones. Señala cuatro defectos de diseño, cada uno con el criterio de la lección que incumple, y propón una alternativa.

Solución 1. Hay cuatro responsabilidades: pedir el nombre validado, pedir las horas validadas, calcular el importe con su descuento y presentar el recibo. La lógica del descuento debe quedar aislada de la entrada y de la salida.

Fíjate en que calcular_importe no imprime ni pregunta: puedes comprobar a mano que calcular_importe(40) da 2200.0 y calcular_importe(41) da 2029.5, sin ejecutar el programa. Y en que el main() tiene tres líneas que se leen como el enunciado del problema.

Solución 2.

Además, el nombre procesar es genérico y no advierte de que modifica el estado global. Un nombre honesto para lo que hace sería pedir_dato_y_acumularlo_en_total: su misma fealdad demuestra que la función está mal partida.

Descomponer un programa no es cortarlo en trozos: es encontrar sus partes. Los criterios son pocos y comprobables: una función, una responsabilidad, verificable con la prueba de describirla sin usar «y»; un tamaño que rara vez pasa de veinte líneas; un nivel de abstracción homogéneo dentro de cada función; entrada, lógica y salida en familias separadas, porque la lógica silenciosa es la única que se puede comprobar de verdad; nombres que anuncian el efecto; DRY para no repetirse, y sentido común para no fragmentar de más. El diseño descendente —escribir el main() como si las funciones ya existieran— es la forma más cómoda de aplicar todo eso, y el bloque if __name__ == "__main__": cierra el fichero para que pueda ejecutarse o importarse.

TareaFácil ha llegado a la versión 0.7. Hace exactamente lo mismo que la v0.6 —ni una función nueva de cara a Marta—, pero su bucle principal ha pasado de setenta y cinco líneas a veintidós, la duplicación ha desaparecido y ocho de sus funciones se pueden reutilizar tal cual en otro programa. El estado de la tarea, eso sí, sigue viviendo en seis variables sueltas que hay que pasar de función en función: es la deuda que el módulo 5 y el 7 vendrán a cobrar. Queda una última sorpresa antes de cerrar el módulo. Hasta ahora las funciones han sido cosas que se llaman; pero en 04-01 viste de pasada que pausar sin paréntesis es un valor con su propio type(). Si una función es un valor, se puede guardar en una variable, pasar como argumento a otra función y devolver desde otra. Eso abre una forma de programar distinta, y es el cierre del módulo: Funciones como valores: lambda y orden superior.