¿Cómo se organizó el proceso de revisión de código en su equipo?

Utilizamos desarrollo conjunto mediante el sistema de control de versiones Git y plataformas de gestión de repositorios (por ejemplo, Bitbucket o GitLab). El proceso de revisión de código se organizó de la siguiente manera:

1. Creación de rama: El desarrollador crea una rama separada para una nueva función o corrección de errores (git checkout -b feature/my-new-feature).
2. Desarrollo y commits: Se realizan cambios en la rama, que se registran mediante commits (git add ., git commit -m "Implementación inicial de la función").
3. Push al repositorio remoto: La rama se envía al repositorio remoto (git push origin feature/my-new-feature).
4. Creación de Pull/Merge Request: El desarrollador crea un Pull Request (en Bitbucket) o Merge Request (en GitLab), indicando la rama objetivo (por ejemplo, develop o main). En la descripción se incluye un resumen de los cambios, enlaces a las tareas en el gestor de tareas (Jira, Trello, etc.) y archivos adjuntos (capturas de pantalla, videos, diagramas).
5. Asignación de revisores: Se asignan uno o dos desarrolladores del equipo para realizar la revisión.
6. Proceso de revisión: Los revisores revisan los cambios en el Pull/Merge Request. Pueden dejar comentarios, sugerir mejoras, hacer preguntas.

   // Ejemplo de comentario durante la revisión
   function fetchData() {
     // Quizás aquí debería añadirse manejo de errores en la solicitud de datos
     return fetch('/api/data');
   }
   

7. Realización de cambios tras la revisión: El desarrollador realiza los cambios necesarios en su rama basándose en los comentarios de los revisores y hace nuevos commits.
8. Actualización del Pull/Merge Request: Los cambios se muestran automáticamente en el Pull/Merge Request tras hacer push al repositorio remoto.
9. Revisión reiterada: Los revisores vuelven a revisar los cambios y dan su aprobación.
10. Fusión de la rama: Tras obtener la aprobación, la rama se fusiona en la rama objetivo (generalmente de forma automatizada por la plataforma tras pasar por el pipeline CI/CD).

También utilizamos pipelines CI/CD para ejecutar automáticamente pruebas unitarias, análisis estático de código (ESLint, Prettier) y construcción del proyecto antes de la fusión, lo que ayudaba a detectar errores en etapas tempranas.

Los criterios para aprobar con éxito la revisión incluían:

• Cumplimiento de los requisitos de la tarea.
• Seguimiento del estilo de código del equipo.
• Inclusión de pruebas unitarias para lógica crítica.
• Ausencia de errores evidentes y "parches".
• Claridad del código para otros miembros del equipo.