Como foi organizada a revisão de código na sua equipa?

Utilizámos desenvolvimento colaborativo com o sistema de controlo de versões Git e plataformas de gestão de repositórios (por exemplo, Bitbucket ou GitLab). O processo de revisão de código foi organizado da seguinte forma:

1. Criação de branch: O desenvolvedor cria uma branch separada para uma nova funcionalidade ou correção de bug (git checkout -b feature/my-new-feature).
2. Desenvolvimento e commits: São feitas alterações na branch, que são registadas por commits (git add ., git commit -m "Implementação inicial da funcionalidade").
3. Push para o repositório remoto: A branch é enviada para o repositório remoto (git push origin feature/my-new-feature).
4. Criação de Pull/Merge Request: O desenvolvedor cria um Pull Request (no Bitbucket) ou Merge Request (no GitLab), indicando a branch alvo (por exemplo, develop ou main). Na descrição, inclui um resumo das alterações, links para as tarefas no gestor de tarefas (Jira, Trello, etc.) e ficheiros anexados (capturas de ecrã, vídeos, diagramas).
5. Atribuição de revisores: Um ou dois desenvolvedores da equipa são atribuídos para realizar a revisão.
6. Processo de revisão: Os revisores analisam as alterações no Pull/Merge Request. Podem deixar comentários, sugerir melhorias, fazer perguntas.

   // Exemplo de comentário durante a revisão
   function fetchData() {
     // Talvez aqui deva ser adicionada gestão de erros na solicitação de dados
     return fetch('/api/data');
   }
   

7. Alterações após a revisão: O desenvolvedor faz as alterações necessárias na sua branch com base nos comentários dos revisores e faz novos commits.
8. Atualização do Pull/Merge Request: As alterações são exibidas automaticamente no Pull/Merge Request após push para o repositório remoto.
9. Revisão reiterada: Os revisores revisam novamente as alterações e dão a sua aprovação.
10. Fusão da branch: Após aprovação, a branch é fundida na branch alvo (geralmente de forma automatizada pela plataforma após passar pelo pipeline CI/CD).

Também utilizamos pipelines CI/CD para executar automaticamente testes unitários, análise estática de código (ESLint, Prettier) e construção do projeto antes da fusão, o que ajudava a identificar erros precocemente.

Os critérios para aprovação na revisão incluíam:

• Conformidade com os requisitos da tarefa.
• Seguir o estilo de código da equipa.
• Inclusão de testes unitários para lógica crítica.
• Ausência de erros evidentes e "gambiarras".
• Clareza do código para outros membros da equipa.