Quando fazer a revisão de código
Recentemente, passamos para um processo de scrum e estamos trabalhando em tarefas e histórias de usuários dentro dos sprints. Gostaríamos de fazer revisões de código com frequência para torná-las menos assustadoras. Estamos pensando em fazê-los no nível da história do usuário, mas não sabemos como ramificar nosso código para explicar isso.
Estamos usando o VS e o TFS 2010 e somos uma equipe de 6 pessoas.
Atualmente, ramificamos recursos, mas estamos trabalhando para mudar para ramificação para scrum.
Atualmente, não usamos prateleiras e realmente não queremos implementar se houver outras técnicas disponíveis.
Como você recomenda que implementemos a revisão de código por história de usuário?
agile code-reviews scrum
— mcass20
Depende da natureza das histórias de usuários.
Pode ser eficaz criar uma ramificação para cada história do usuário, o progresso em diferentes histórias é visível, elas podem ser contornadas, se necessário, se as histórias não forem concluídas no sprint, o progresso poderá permanecer no ramo para o próximo sprint . As revisões finais podem ser executadas no final de uma história do usuário no ramo da história de uso e mescladas se o código estiver no padrão.
Para trabalhar da maneira que as histórias precisam ser refinadas, para evitar tarefas de mesclagem incontroláveis ​​no final de um sprint. Histórias pequenas permitirão uma atualização constante da ramificação do desenvolvedor por meio do sprint que os desenvolvedores que trabalham em outras histórias de usuários precisam obter constantemente (VCM básico).
Isso cria despesas gerais do 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 um sprint, você mescla seu ramo de desenvolvimento na integração / produção, etc.
Também trabalhei em equipes nas quais todos trabalham em uma ramificação de desenvolvedor, após a conclusão de uma história de usuário, o código é enviado para essa ramificação para revisão e teste e se alguém fornece algo que quebra a construção do desenvolvedor, eles precisam obter as cervejas da equipe.
A maneira mais eficaz de revisar o código é levantar-se, encontrar alguém e pedir que ele venha e discuta o código que você 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 revisões de código por meio de emparelhamento.
Eu queria saber quando alguém iria mencionar o emparelhamento. Entre isso e o teste de unidade, você recebe muitas análises.
— JeffO 8/03
Eu li isso como "levante-se, demitir alguém e pedir que eles venham discutir o código que você acabou de desenvolver". Obrigado por fazer o meu dia.
— Will Morgan
Todos na equipe são locais? Nesse caso, basta pedir a alguém para dar uma olhada antes que o código seja verificado. Não é local? Inicie o seu programa de compartilhamento de tela favorito e ligue para alguém. Eu pessoalmente faço isso frequentemente. Às vezes eu faço isso apenas para dizer "Ei, olha o que eu fiz!"
Eu prefiro esse estilo de revisão de código ad-hoc ao estilo em que alguém está se levantando e apresentando seu código à equipe. As análises ad-hoc podem oferecer muitos (todos?) Dos benefícios do emparelhamento sem o embaraço. Além disso, é mais provável que o seu "revisor" faça perguntas e sugira melhorias em um ambiente informal e individual.
— jgrim
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 obter qualidade e melhorar seus projetos / equipe.
Portanto, 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) independentemente 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.
Portanto, para responder sua pergunta, acredito que você esteja tentando empurrar muito do SCRUM, e é melhor considerar as revisões apenas como são.
— Ron-Damon
Scrum não diz nem aconselha nada sobre horário. Ele espera que você agregue valor regularmente. Ele também fornece momentos em que você pode inspecionar e adaptar seu processo para melhorar (melhor não necessariamente significando mais rápido).
Sim, o Scrum não declara fazer uma programação completa como parte dela. Ainda assim, eu quis dizer "planejamento" quando me referi à programação, planejamento, o que significa que seu cliente espera algum valor em um determinado período, para que eles possam realizar a troca entre o valor do dinheiro v / s (se você considerar que está fornecendo serviços de desenvolvimento / programação) )
Nesse caso, seu cliente deve ter um orçamento para gastar em um determinado período (para pagar você, por exemplo) e ele pode ter um cronograma para atender. Eu trabalho como prestador de serviços, é por isso que não posso deixar esse fato de lado.
Contratos à parte, as equipes Scrum entregam valor, não serviços. Desenvolvemos / programamos como um meio de entregar esse valor.
Não acredito que você possa separar os termos "valor" e "serviço" amigo. Eu também acredito que isso é muito fora de tópico agora.
Não é óbvio fazer revisões de código antes de fazer o check-in?
O TFS não funciona como o GIT, portanto, sempre que você faz o check-in de um ramo ou tronco, ele está disponível para todos.
Isso significa que a revisão deve ocorrer no check-in para que alterações ruins não sejam propagadas para a cópia de trabalho de todos.
— Byron Whitlock
Eu acho que, em geral, os testes de unidade são o que impediria mudanças ruins.
@ John Saunders: considere as revisões de código como outro tipo de teste de unidade.
— Gilbert Le Blanc
@ Gilbert: Eu poderia fazer isso, mas não receberia o benefício deles para testes de regressão. Eu preferiria gastar o tempo escrevendo mais e melhores testes de unidade.
@ John Saunders, as revisões de código de Gilbert Le Blanc são realizadas por outro desenvolvedor, os testes de unidade geralmente são feitos pelo desenvolvedor original, a nova perspectiva pode ser vital.
Eu tive sorte com testes de unidade (as listas de testes são acordadas com antecedência) e análise de código automatizada, possivelmente combinada com uma ferramenta de análise de estilo como o StyleCop. Mas não costumo trabalhar com desenvolvedores juniores.