Quando fazer uma revisão de código

15

Recentemente, mudamos para um processo scrum e estamos trabalhando em tarefas e histórias de usuários dentro de sprints. Gostaríamos de fazer revisões de código com frequência para torná-las menos assustadoras. Estamos pensando em fazê-las em um nível de história do usuário, mas não temos certeza de como ramificar nosso código para explicar isso.

Estamos usando o VS e o TFS 2010 e somos uma equipe de 6 pessoas.

Atualmente, nos ramificamos para recursos, mas estamos trabalhando para mudar para ramificação para scrum.

No momento, não usamos shelvesets e realmente não queremos implementá-los se houver outras técnicas disponíveis.

Como você recomenda a implementação da revisão de código por história do usuário?

    
por mcass20 08.03.2011 / 20:14
fonte

5 respostas

3

Depende da natureza das histórias do usuário.

Pode ser eficaz criar uma ramificação para cada história de usuário, o progresso em diferentes histórias é visível, elas podem ser repassadas se necessário, se as histórias não forem concluídas no sprint, o progresso pode permanecer na filial para o próximo sprint. As revisões finais podem ser realizadas no final de uma história de usuário no ramo de história de uso e mescladas se o código estiver de acordo com o padrão.

Para trabalhar de maneira, as histórias precisam ser refinadas para evitar tarefas de mesclagem incontroláveis no final de um sprint. Pequenas histórias permitirão uma atualização constante do ramo de desenvolvimento através do sprint que os desenvolvedores trabalhando em outras histórias de usuários precisam constantemente extrair (VCM básico).

Isso cria overheads de processo que precisam criar e mesclar ramificações constantemente, o que, em alguns casos, pode ser resolvido com scripts de automação, mas a equipe ainda precisa estar muito confortável com o VCS.

No final de uma sprint, você mescla sua ramificação dev em integração / produção, etc.

Eu também trabalhei em equipes onde todo mundo trabalha em um ramo de desenvolvimento, na conclusão de uma história de usuário, o código é enviado para aquele ramo para revisão e teste e se alguém empurra algo que quebra o desenvolvimento de desenvolvimento, ele precisa cervejas em.

    
por 08.03.2011 / 20:35
fonte
13

A maneira mais eficaz de rever o código é levantar-se, encontrar alguém e pedir-lhe que venha e discuta o código que acabou de desenvolver.

Não use uma ferramenta, a menos que você não encontre alguém para revisar seu código localmente.

Você pode evitar totalmente as revisões de código emparelhando.

    
por 08.03.2011 / 22:32
fonte
4

Todos na equipe são locais? Se assim for, basta pedir a alguém para vir e dar uma olhada antes que o código seja registrado. Não é local? Abra seu programa favorito de compartilhamento de tela e ligue para alguém. Eu pessoalmente faço isso com frequência. Às vezes eu faço apenas para dizer "Ei, olha o que eu fiz!"

Eu prefiro muito mais esse estilo de revisão de código ad-hoc ao estilo em que alguém está em pé e apresentando seu código para a equipe. Revisões ad-hoc podem lhe dar muitos (todos?) Dos benefícios do emparelhamento sem o constrangimento. Além disso, é mais provável que seu "revisor" faça perguntas e sugira melhorias em um ambiente informal e individual.

    
por 09.03.2011 / 00:54
fonte
1

Eu acredito que a revisão de código não é uma parte formal do SCRUM, mas as revisões são uma tática independente para alcançar a qualidade e melhorar seus projetos / equipe.

Então, você usaria o SCRUM (ou outra metodologia de desenvolvimento ágil) para garantir / melhorar a qualidade do PROJETO e manter o cronograma. Além disso, uma boa tática é fazer a revisão do produto (não o código) de forma independente de suas tarefas normais de controle de qualidade / teste. Se essa atividade puder ser realizada na frente de sua equipe / parceiros / clientes / público, será melhor.

Você deve usar revisões de código (ou outras específicas) principalmente para melhorar sua EQUIPE, esperando resultados a médio / longo prazo. Isso afetará seus PROJETOS, mas a longo prazo, como um produto da melhoria de sua equipe.

Então, para responder a sua pergunta, acredito que você está tentando empurrar muito do SCRUM, e você deve considerar melhor as revisões apenas como estão.

    
por 08.03.2011 / 22:07
fonte
0

Não é óbvio fazer revisões de código antes de verificar seu código?

O TFS não funciona como o GIT, portanto, sempre que você verificar o código em uma ramificação ou no tronco, ele estará disponível para todos.

Isso significa que a revisão deve acontecer no check-in, por isso as alterações ruins não são propagadas para a cópia de trabalho de todos.

    
por 08.03.2011 / 20:16
fonte