Python. Project Structure (& X)

#python #ci #cd #docker

Índice:

Sección A. Estructurar un proyecto: apartado I, apartado II, apartado III, apartado IV, apartado V, apartado VI, apartado VII, apartado VIII, apartado IX, apartado X.

En este último apartado de la sección "Estructurar un proyecto" hablaremos de la revisión de código en grupo.

La revisión de código es una parte fundamental para el trabajo en grupo en equipos de desarrollo, por ello es necesario tener claros los límites y alcances.

Es imprescindible mantener unas buenas prácticas para que una revisión de código sea un factor de mejora de las interrelaciones del grupo:

El foco tiene que ser estricto: se habla del tema y solo del tema. Después habrá tiempo para otras cosas.
Se revisa el código, nunca se habla de las personas que lo escribieron ni porqué; solo una revisión empática y profesional podrá ser constructiva. Todos deben entender que es un momento para entablar una conversación con la mente abierta y mejorar el trabajo en equipo para el futuro.
Siempre limitamos el tiempo; cuanto más corta más eficaz, cuanto más larga más pesada.
No se realizan a diario, ni semanalmente: solo cuando son necesarias.
Recuerda que: si acudes a la reunión sin haber leído mínimamente el código y el objetivo de la reunión, te convertirás en un troll que destrozará todo el mobiliario y amistades.

Fase 1: preparación

En esta fase nunca revisamos código. ¿Qué se hace?

Definir el alcance: seleccionamos un componente, archivo, módulo, que esté causando errores y que sea crítico para el negocio; o, que por urgencia haya que actuar con celeridad.
Preparar el contexto (y el código involucrado): haremos un breve resumen de qué hace el código, cual es su importancia y los problemas o dudas que se deben resolver. En este punto es habitual tener unas primera preguntas u observaciones sobre las que empezar a hablar.
Acceso al código: debemos asegurarnos que todas las personas del grupo tienen acceso y han podido revisar mínimamente el código para saber sobre qué se va a trabajar.

Fase 2: la reunión

Deben estar limitadas a 30 ó 60 minutos como mucho. No es una reunión para escribir código, es una reunión para encontrar soluciones.
Para evitar las confusiones y desapegos es necesario mantener unas ciertas reglas:
- una persona será el moderador, manteniendo el enfoque en la reunión y asegurándose que todos participen.
- habrá también un presentador (en equipos muy pequeños puede ser el mismo moderador), que se encargará de mostrar el código y explicar las decisiones que llevaron a escribir dicho código; por ello es importante que preferiblemente sea quien escribió el código o alguien que esté al corriente del mismo.
- y los revisores, el resto de personas involucradas en el equipo. Su principal enfoque es repreguntar el código, detectar posible fallos y proponer mejoras.
La sesión la dividiremos en tres partes:
- La introducción, corta (5 minutos o poco más); en ella se explica el objetivo del código y el problema que tenemos o en qué debemos enfocarnos.
- Revisión del código (esta es la parte gruesa del tiempo ocupado), donde se mostrarán las secciones del código explicando su intención y lógica. No se lee el código línea a línea. En consecuenca, surgirán posibles temas de debate:
- Arquitectura. ¿Se repestan los patrones de diseño (SOLID, DRY, etc.)?
- Mantenibilidad. ¿Qué dificultad aporta su diseño para que un nuevo desarrollador que lo desconoce pueda cambiar la lógica del código (refactor)?
- Escalabilidad. ¿Será igualmente eficiente cuando evolucione?
- Test. ¿Es posible simplificar los tests de las funcionalidades afectadas?
- Resultados. Una vez terminada la sesión, el moderador o la persona que se encargara habrá tomado notas y se revisarán en conjunto para clasificar las actuaciones y nombrar un responsable según sean:
- Actuaciones críticas: bugs, seguridad. Saldrá un grupo o persona encargada de que se solucione urgentemente.
- Importantes: diseño o refactorización. Se programará una tarea a futuro con un responsable.
- Mejoras: pequeños retoques o de estilo. Se valorará si el beneficio merece el esfuerzo y tiempo.

Fase 3: seguimiento

El resultado de la reunión quedará por escrito, documentada con una lista de acciones y responsable utilizando la herramienta deseada.

Los responsables designados se encargarán de realizar o establecer los equipos responsables de actuar.

Para el cierre de los tickets/incidencias/refactor (o como se quiera categorizar) es necesario que el presentador de la reunión muestre su conformidad con el resultado obtenido.