Suspeito que uma grande revisão de código oculte minha equipe. Muitas revisões de código são mescladas sem nenhum comentário.

Parece-me que não existe uma revisão de código sem um único comentário.

Como eu, como líder de equipe, monitore adequadamente se minha equipe está executando um processo de revisão de código adequado e como posso ajudá-los a maximizar os benefícios do processo?

Atualizar

As pessoas que pensam podem querer saber sobre qualquer atualização. Eu tentei muitas sugestões que foram dadas aqui. a maioria já estava em uso. alguns ajudaram um pouco. No entanto, o problema permaneceu - algumas pessoas obtiveram códigos incorretos continuamente quando eu não estava olhando.

Descobri que o monitoramento da revisão de código não é tão útil quanto fornecer ferramentas à minha equipe para melhorar seu código, para começar.

Então, adicionei uma biblioteca chamada "jscpd" para detectar pastas de cópia. A construção falhou nas pastas de cópia. Isso eliminou um problema imediatamente.

Em seguida, tentaremos o codeclima.

Também estou fazendo uma revisão manual de revisões antigas de código uma vez por sprint por meio dia. Estou convertendo todos em problemas / tíquetes - como descobri que as pessoas os escrevem, mas nunca são tratados posteriormente. Também estou realizando reuniões com as equipes inteiras para revisar o código quando for apropriado.

em geral, parece que estamos nos movendo na direção certa.

Vou oferecer uma visão diferente dos meus colegas atendentes. Eles estão certos - participe se você quiser ver como as coisas vão. Se você deseja mais rastreabilidade, existem ferramentas para isso.

Mas, na minha experiência, suspeito que haja algo mais acontecendo.

Você considerou que sua equipe pode achar que o processo está quebrado / estúpido / ineficaz para a maioria dos commits? Lembre-se, o processo está documentando o que funciona bem, não as regras a serem obedecidas . E como líder da equipe, você está lá para ajudá-los a serem os melhores, não a impor regras.

Portanto, em suas retrospectivas (se for ágil) ou em uma (se você for um gerente) ou em reuniões aleatórias improvisadas no corredor (se você for um líder de equipe não-ágil e houver outro gerente fazendo um a um), traga-o à tona . Pergunte o que as pessoas pensam do processo de revisão de código. Como está funcionando? Como não é? Digamos que você ache que talvez não esteja beneficiando a equipe o máximo possível. Certifique-se de ouvir .

Você pode defender algumas revisões de código nessas reuniões, mas é melhor ouvir os comentários. Provavelmente, você descobrirá que a sua equipe acha que o processo "adequado" precisa ser ajustado ou que existe alguma causa raiz (pressão do tempo, falta de revisores, Bob apenas confirma o código dele, por que não podemos) resolver .

Forçar uma ferramenta em cima de um processo quebrado não tornará o processo melhor.

Não gosto de postar respostas em uma linha, mas esta parece apropriada:

Participe do processo.

Obtenha uma ferramenta, como ReviewBoard ou o plug- in de revisão de código do Redmine . Em seguida, cada revisão é criada como uma tarefa que precisa ser fechada ou comentada por alguém (como um ticket de bug). Então você tem rastreabilidade de quem criou o ticket de revisão e quem o fechou. Você pode amarrar tickets de revisão com check-ins de código-fonte, ou seja, criar o ticket a partir de uma revisão.

Algumas coisas (para ser honesto, a maioria delas é coberta por respostas, mas eu queria colocá-las em um único lugar)

• Você pode implementar o processo e as regras para garantir que uma revisão de código aconteça, mas é praticamente impossível inseri-las para que a revisão de código seja realmente mais do que um exercício de seleção de caixa. Por fim, a equipe precisa ver os benefícios do processo, se quiser abordá-lo de maneira útil.

• Lidere pelo exemplo. Participe de revisões. Como desenvolvedor, me sinto mal se meu gerente (agora não desenvolvedor) detectar coisas que não identifico. Destaque os problemas que deveriam ter sido capturados na revisão (de uma maneira que não culpe). Se ocorrer um problema de produção, se surgirem problemas durante o controle de qualidade (se você tiver um processo de controle de qualidade separado), destaque onde eles poderiam ter sido detectados na revisão de código. Discuta com a equipe como podemos garantir que problemas futuros sejam capturados

• Discuta com a equipe o que eles querem que o processo faça. Se eles não entenderem (como pode acontecer no início), use os problemas de produção e os refixos necessários como evidência de seu benefício.

• Use um software automatizado de verificação de código, como o Sonarqube, para que as revisões de código possam se concentrar em questões como código incompreensível, erros lógicos, falta de documentação etc. que não podem ser detectados automaticamente.

Você pode documentar o que a equipe deseja nas revisões de código que discutiu e concordou com os desenvolvedores. Algumas coisas que você pode considerar como parte das análises de código são:

• Verifique se o código faz o que deve fazer, ou seja, atende aos requisitos

• Estilo de código para garantir que os desenvolvedores estejam codificando para um estilo consistente

• Otimização, por exemplo, número de chamadas de função

• Arquitetura e reutilização

• Tratamento e registro de exceções

• Dívida técnica: o código está em um estado melhor do que quando o desenvolvedor começou a trabalhar nele

• Confira e construa o código (acho isso útil, mas outros desenvolvedores da minha equipe preferem deixar isso para os testadores)

• Usando uma ferramenta automatizada (usei o SonarQube ). Acho útil integrar isso ao seu processo de compilação para impor melhorias no código, por exemplo, aumentando a cobertura do teste

Algumas das etapas acima podem ser abordadas por uma ferramenta automatizada, mas enquanto você tenta melhorar a maneira como as revisões ou o código são feitos, provavelmente vale a pena usar a ferramenta e a revisão do globo ocular. No entanto, as etapas mais importantes para evitar dívidas técnicas (arquitetura e reutilização) não podem ser totalmente automatizadas.

Se sua equipe for inconsistente ao aplicar isso, tente apenas permitir que os desenvolvedores que estão realizando as análises de código corretamente tenham direitos de mesclagem. Por exemplo, você pode apenas querer começar com o desenvolvedor líder da equipe. A desvantagem dessa abordagem é que esses desenvolvedores podem se tornar um gargalo no processo de desenvolvimento, portanto você e a equipe precisam decidir se deseja isso. Pessoalmente, eu aceitaria essa troca e, através das revisões de código, aumentaria a disciplina em todo o restante da equipe e, quando estiver pronto, você poderá aumentar o número de desenvolvedores com direitos de mesclagem.

Finalmente, vale a pena revisar os comentários. Portanto, uma vez por semana, reúna-se com os desenvolvedores e discuta construtivamente as análises e formas de aprimorá-los.

Vou contar como minha equipe integrou rapidamente a revisão de código em seu fluxo de trabalho.

Primeiro, deixe-me fazer uma pergunta. Você está usando um sistema de controle de versão (por exemplo, Mercurial, Git)?

Se sua resposta for sim, prossiga.

1. proibir todo mundo de enviar qualquer coisa (até pequenas correções) diretamente para o ramo principal (tronco) *
2. desenvolver novos recursos (ou correções) em ramificações separadas
3. quando os desenvolvedores acreditam que o ramo está pronto para ser integrado ao mestre, eles criarão uma "solicitação de recebimento"
4. proibir todos de mesclar sua própria solicitação de recebimento *
5. outro desenvolvedor avalie a solicitação pull e revise o novo código
6. se o código passar na revisão, bom, a solicitação de recebimento pode ser mesclada, caso contrário, correções podem ser aplicadas
7. repita a etapa 6 até o código amadurecer o suficiente (pode ser feito sem começar de novo) **
8. feito, todo o seu novo código é revisado (pelo menos sumariamente) por alguém com um nome

Agora você tem um ponto preciso no seu fluxo de trabalho em que a revisão do código é feita.

Aja lá.

* pode ser aplicado automaticamente, com ganchos do lado do servidor

** este procedimento é totalmente suportado pelo GitHub (entre outros) e é bastante fácil de usar, confira

Acho que você deve criar um modelo e pedir aos membros da sua equipe que o atualizem toda vez que fizerem uma revisão de código. Mas, mesmo assim, você deve participar do processo de revisão inicialmente.