5.1Código limpio & patrones de diseño (PEP 8, SOLID)
Lo esencial en 30 segundos
- PEP 8 automatizada : nombrado y formato previsibles — black/ruff deciden, ya no se debate el estilo en revisión.
- SOLID pragmático : una responsabilidad por unidad, depender de abstracciones — sin dogma en los pequeños scripts.
- Patrones nombrados : Factoría, Estrategia, Adaptador, Contexto — un nombre vale diez frases de explicación.
Mini-caso hilado — Nabil ordena sus scripts en Argel
Nabil, analista de datos junior en Argel, compagina scripts de análisis que « funcionan » pero que nadie relee sin hacer muecas : nombres crípticos, función gigante que carga, limpia, calcula y muestra, estilo distinto en cada archivo. Aplica black/ruff, renombra en explícito y divide la función gigante en unidades de responsabilidad única. Esta sección cuenta su paso al código pro — y el hilo continúa en 5.2, 5.3 y 5.4.
Este mismo caso vuelve en el curso, el esquema, el guion y el reto 48h — y continúa en 5.2, 5.3 y 5.4.
1. PEP 8 : la gramática común
En el nivel pro, el código se relee más de lo que se escribe. La PEP 8 es la guía de estilo oficial de Python : snake_case para las funciones, PascalCase para las clases, UPPER para las constantes, líneas contenidas, dos líneas entre funciones. Seguirla hace que todo código sea previsible : un lector sabe dónde mirar. Nabil deja de reinventar su estilo en cada script — adopta la gramática común.
El punto decisivo : el estilo se automatiza. black reformatea, ruff (o flake8/pylint) señala los desvíos — el estilo ya no se debate en revisión, la herramienta decide. Se instala, se lanza antes de cada commit, se corrige lo señalado.
2. SOLID en práctica (sin dogma)
SOLID guía el despiece : una sola responsabilidad por función o clase, abierto a la extensión (parámetros, plugins) pero cerrado a la modificación (añadir sin romper), depender de abstracciones en lugar de detalles concretos — en Python, el duck typing ayuda (« si grazna, es un pato »). Nabil divide su función gigante : una función carga, otra limpia, una tercera calcula — cada una testeable.
Pero el pragmatismo prima : un pequeño script desechable no necesita una fábrica abstracta. Se estructura lo que crece y dura, se deja simple lo puntual. El god-object que lo hace todo y la fábrica de gas para cincuenta líneas son los dos extremos por evitar.
3. Los patrones que rentan
Los patrones de diseño son soluciones probadas a problemas de diseño recurrentes. Los que rentan rápido en Python : la Factoría (crear el objeto según la config), la Estrategia (algoritmos intercambiables — el diccionario de funciones del ejemplo), el Adaptador (unificar API distintas tras una misma interfaz), el Contexto (un with casero vía contextlib para gestionar limpiamente los recursos). Nabil sustituye su cascada de elif por una estrategia nombrada : añadir un modo se vuelve añadir una entrada.
Extra de equipo : un patrón nombrado en una revisión vale diez frases de explicación — « es una estrategia » lo dice todo. Se descubren según las necesidades, nunca de memoria de golpe.
🔎 Ejemplo concreto — Nabil sustituye sus elif por una estrategia
Antes/después black + estrategia nombrada.
# AVANT : rigide
def calculer(mode, x):
if mode == "tva":
return x * 1.2
elif mode == "remise":
return x * 0.9
# APRES : strategie nommee
STRATEGIES = {"tva": lambda x: x * 1.2, "remise": lambda x: x * 0.9}
def calculer(mode, x):
return STRATEGIES[mode](x)Lectura : añadir un modo = una entrada en el diccionario, no un elif más.
Lección : black . + ruff check . antes de cada commit.
Vocabulario de la sección
- PEP 8
- La guía de estilo oficial de Python, que hace previsible todo código.
Ejemplo sencillo: Nabil renombra sus variables en snake_case explícito.
Lo que no es: una herramienta que acelera la ejecución.
Reflejo: ¿un desconocido leería mi código sin esfuerzo?
- Código limpio
- Código legible : nombres explícitos, funciones cortas, cero duplicación.
Ejemplo sencillo: Nabil divide su función gigante en tres unidades testeables.
Lo que no es: código que funciona pero que no se osa releer.
Reflejo: ¿cada función tiene una sola responsabilidad?
- black / ruff
- Herramientas que formatean (black) y controlan el estilo (ruff) automáticamente.
Ejemplo sencillo: Nabil lanza black y luego ruff antes de cada commit.
Lo que no es: un debate de estilo a mano en revisión.
Reflejo: ¿la herramienta ha decidido antes de la revisión?
- SOLID
- Principios de despiece hacia un código desacoplado y mantenible, por aplicar sin dogma.
Ejemplo sencillo: Nabil abre a la extensión por parámetros en lugar de modificar.
Lo que no es: una lista de control por marcar a ciegas.
Reflejo: ¿esta estructura paga su coste?
- Estrategia
- Patrón : algoritmos intercambiables tras una misma interfaz.
Ejemplo sencillo: Los modos de cálculo de Nabil se vuelven entradas del diccionario.
Lo que no es: una cascada de elif que se alarga.
Reflejo: ¿puedo añadir un caso sin tocar lo existente?
En la práctica — Dejar su código limpio y conforme
- Retomad un script antiguo y renombrad sus variables/funciones de forma explícita (snake_case, nombres parlantes).
- Instalad black (pip install black) y lanzadlo sobre el archivo : observad el formato automático y uniforme.
- Instalad flake8 y corregid las advertencias de estilo que señala.
- Dividid una función demasiado larga en varias funciones cortas de responsabilidad única : medid la ganancia en legibilidad.
Guion listo para decir — proponer el estilo auto
« En Argel, nuestros scripts de análisis funcionan pero se releen mal : estilos distintos, nombres crípticos, funciones gigantes. Propongo fijar PEP 8 con black y ruff antes de cada commit, y dividir la función más dolorosa en unidades de responsabilidad única. Medimos la ganancia en relectura, luego ampliamos. »
Para decir en revisión para adoptar el formato auto sin prometer una reescritura completa.
Modelo copiar-pegar — lista de control relectura limpia
RELECTURE CODE PROPRE (1 fichier)
NOMMAGE : snake_case fonctions / PascalCase classes / UPPER constantes ? ___
DECOUPE : chaque fonction a-t-elle UNE seule responsabilite ? -> A decouper : ___
DUPLICATION : meme logique a 2 endroits ? -> A factoriser : ___
OUTILS : black passe ? ___ · ruff check propre ? ___
PATTERN : un elif qui s'allonge -> strategie envisageable ? ___Solo / presupuesto pequeño
Nabil solo : black + renombrado explícito sobre el script más releído basta — sin reescritura completa.
PYME / equipo reducido
Un pre-commit black/ruff compartido : todo el equipo produce el mismo estilo sin discutirlo.
PYME en Argel
Nabil fija una relectura mensual en Argel : una función gigante dividida cada vez, patrones nombrados en revisión.
Equipo que empieza
Pareja : uno codifica, el otro relee con la lista de control ; solo se añade un patrón ante dolor real.
✓ Buenas prácticas
- black/ruff en pre-commit : el estilo lo decide la herramienta.
- Una responsabilidad por unidad : dividir primero la función más dolorosa.
- Nombrar los patrones en revisión : un nombre compartido vale diez frases.
✗ Errores frecuentes
- Debatir el estilo a mano en lugar de automatizar.
- Montar una fábrica de gas para cincuenta líneas.
- Dejar un god-object que lo hace todo (cargar, limpiar, calcular, mostrar).
Puntos clave
- PEP 8 es el estilo oficial de Python : seguirlo hace el código familiar para todos.
- Código limpio = nombres explícitos + funciones cortas + cero duplicación.
- black reformatea automáticamente ; flake8/pylint detectan los defectos.
- Los patrones de diseño son soluciones probadas a los problemas de diseño recurrentes.
Reto 48h — aplica mañana
Pasad 1 script de Nabil por black + ruff, renombrad 5 nombres crípticos y dividid 1 función gigante : ¿la relectura es más rápida?
- Puedo explicar PEP 8 y el papel de black/ruff en una frase.
- Mi script está reformateado y sin advertencia bloqueante.
- Sé cuándo NO añadir un patrón.
Preguntas frecuentes
¿El estilo del código importa de verdad si funciona?
Sí, muchísimo. Un código se lee mucho más a menudo de lo que se escribe. Un estilo coherente reduce los bugs, acelera la relectura y facilita el trabajo en equipo. Es un criterio mayor en empresa : un código limpio es un código profesional. Y con black/ruff, ese estilo no cuesta casi nada : la herramienta lo garantiza antes de cada commit.
¿Hay que aprender todos los patrones de diseño?
No, sobre todo no de memoria. Comprended primero los principios del código limpio. Descubrid los patrones según las necesidades : cuando un problema de diseño vuelve, suele existir un patrón que lo resuelve elegantemente. Conocerlos de nombre ayuda a reconocer esas situaciones — Factoría, Estrategia, Adaptador y Contexto ya cubren lo esencial del día a día Python.
¿Qué define la convención PEP 8?