# Página nuevaRevisión (Peer Review + Code Reviewer)

#### **Revisión (Peer Review + Code Reviewer)**

##### **Asignación de Pares (base)**

- Jordan → Fiorella, Flavio (6)
- Marco → Gabriel, Pierito (2)
- Edson → Daisy, Elian (2)
- José → Jordy, Marcelo (2)

Rotación semanal

##### **Revisión Cruzada entre Seniors**

- Jordan ↔ Edson / APP
- Marco ↔ José

##### **Reglas Anti‑Cuello de Botella**

- Tiempo de revisión: máx. 15 min (peer) / 15 min (checklist code reviewer).
- Toda revisión se responde en ≤ 2 horas hábiles. Si no, escalar al “revisor del día”.
- Automatización obligatoria. (PENDIENTE)

##### **Checklist Peer Review (rápido) / PROGRAMADOR**

1. Nombres claros, funciones cortas, sin duplicaciones.
2. Validaciones de entrada y mensajes de error adecuados.
3. Evitar queries dentro de bucles; revisar índices/joins.
4. Los archivos coinciden con el alcance.

##### **Checklist Code Reviewer (crítico)**

1. Seguridad: sanitización, queries parametrizadas.
2. Performance: consultas pesadas detectadas, uso de caché cuando aplica.
3. Pruebas/CI: linters ok, tests mínimos verdes, build sin warnings críticos.(PENDIENTE)
4. Higiene del MR: sin cambios ajenos, commits limpios, descripción con rutas/archivos.

##### **Flujo Operativo (resumen)**

1. Dev (misma rama dev) → el programador documenta archivos/rutas tocadas en la tarea.(TRABAJANDO)
2. Peer Review → el par asignado revisa código + funcionalidad mínima. (INSERT DE REVISIÓN CÓDIGO)

![](https://shalom-documentation.shalomcontrol.com/uploads/images/gallery/2025-11/embedded-image-aqlmufsc.png)

3. QA → prueba funcional completa. (ÁREA DE QA)
4. Commit/MR por tarea a pre‑prod → Code Reviewer aplica checklist crítico. (PENDIENTE DE PULL)
5. Merge a pre‑prod → validación en entorno estable.