# Propuesta Limitación complejidad y revisiones MRs

###### tags: `foro`

## 1. Introducción

En la actualidad nos encontramos con proyectos más complejos que requieren equipos de trabajo más numerosos y heterogéneos, por lo que cada vez ocupa mayor importancia optimizar el proceso de revisiones de código para asegurar con la mayor certeza posible que nuestro código cumple con los estándares de cálidad adecuados, además de cubrir con la necesidad funcional que intenta solventar.

Dada esta naturaleza, el trabajo diario nos depara un número mayor de MRs diarios, y dada la magnitud de las funcionalidades que implementamos, estos MRs son cada vez más complejos.

Con estas pautas que pasamos a enumerar nuestra intención es optimizar este proceso para hacer el día a día más sencillo tanto a los desarrolladores como a los revisores garantizando que nuestro trabajo sea de la mayor calidad posible con dos claros objetivos: **reducir la complejidad** de cada merge request y **mejorar el procedimiento de revisión**.

## 2. Complejidad de un MR

¿Cómo definimos la complejidad de un MR?
* Como desarrollador:
* ¿Cuándo pensamos que un MR es complicado?
* ¿Cuándo pensamos que un MR es grande?
* Como revisor:
* ¿Cuándo pensamos que un MRs es sencillo de revisar?
* ¿Qué MRs se revisan inmediatamente o cuáles se quedan durante bastantes días pendientes?

### 2.1 Matriz de complejidad

> Tamaño x Dificultad = Complejidad

* **Tamaño**: *Grande* o *Pequeño* (casos generales)
* **Número de ficheros**: Consideramos aceptable en torno a 30 cambios de archivos. A partir de aquí son grandes
* **Número de líneas modificadas**: Consideramos aceptable hasta 600 cambios de líneas. A partir de aquí se consideran grandes.

* **Dificultad**: *Fácil* o *Dificil*

Ejemplos:
* **Pequeño y fácil**:
* Rápido de revisar.
* Fácil de probar.
* Poco probable que provoquen problemas.
* Tiende a mezclarse rápidamente.
* Ej: Cambiar la tipografía del texto de una pantalla.
* **Grande y fácil**:
* Se tarda algo más en revisarse por el tamaño.
* Cambios triviales.
* Poco probable que causen problemas.
* Ej: Refactorizar el nombre de una dimensión usada en la mayoría de layouts.
* **Pequeño y dificil**:
* Pocas líneas de mucho impacto.
* Hay que dedicar bastante tiempo en pruebas.
* Mucha probabilidad de provocar errores.
* Ej: Actualizar una dependencia de librería, cambio en lógica de negocio, etc.
* **Grande y dificil**:
* Muchas líneas y con un impacto importante.
* Mucho tiempo para probar.
* Debemos evitarlos a toda costa.
* Alta probavilidad de causar errores.
* Ej: Una nueva funcionalidad completa.

### 2.2 Etiquetado de complejidad de un MR

¿Porqué surge la idea de etiquetar?

Básicamente no tenemos una visión global de la complejidad del MR cuando entramos en la pantalla de Abiertos. La idea no es revisar los sencillos antes de los complejos, sino ver a primera vista su complejidad para organizar en qué momento lo revisamos

MRs en Inditex Core. No sabemos la complejidad de cada uno, no se cuanto tardaré en revisarlo.


La idea sería a cada uno de los grupos de complejidad definidos asignarles una etiqueta para así identificar en que grupo se situa nuestro MR, cosa que hará el desarrollador al abrir dicho MR.

* ETIQUETAS:
* PF: Pequeño y fácil
* GF: Grande y fácil
* PD: Pequeño y dificil
* GD: Grande y dificil

## ¿Cuántos MRs debo revisar al día mínimo?

## Etiquetado de excepción de un MR

Marcaremos los MRs que salgan de la norma de limitación de tamaño con las siguientes:
* `[recursos]`, `[refactor]`, `[dependencias]`, `[versionado]`, `[block]`

## Técnicas para reducir complejidad de un MR

### Describir MR

Redactar de manera clara y concisa la funcionalidad que pretende solucionar el MR.

### Diseño de UI

En la descripción de los MR:
* Incluir capturas del diseño que hemos realizado.
* Si es un cambio, mostrar el antes y después.
* Si la aplicación soporta diferentes formatos (móvil y tablet) incluirlo.
* Si la aplicación soporta rotación de pantalla, mostrar ambos formatos.

### Ramas intermedias

* Funcionalidad: `[CORE] Feature/Product List`
* División:
* `[CORE] Feature/Product List: DB`
* `[CORE] Feature/Product List: WS`
* `[CORE] Feature/Product List: Domain`
* `[CORE] Feature/Product List: UI`
* `[CORE] Feature/Product List: Integration`

## Procedimiento de revisión

### Objetivos

- Invertir entre el 10-20 % del esfuerzo diario (si hay MRs abiertos). Entre 4 y 8 horas semanales.
- Franjas horarias de revisión. Planificar nuestro tiempo.
- No revisar MRs a la ligera con la excusa de no tener tiempo. Requerir tareas en el proyecto para labor.
- Todos los proyectos revisados (interesa cruzar entre equipos no sólo para los que tienen un número insuficiente de miembros, sino usarlo para aprender).

### ¿Qué pauta seguir para revisar los MRs?

Partimos de la bases:

- Dedicación diaria para esta labor.
- MRs limitados y marcados en complejidad.
- Se revisan los más antiguos primero, sea cual sea su dificultad.
- Todos debemos revisar mínimo 10 MR a la semana.
- Si el volumen de MR en nuestro proyecto no llega a eso, realizar revisiones cruzadas en otro proyecto.

https://git.sdos.es/inditex/core/-/wikis/Pautas-para-revisar-MR#pautas-para-descripciones-de-mr