Sou desenvolvedor de software em uma equipe de 7-8 desenvolvedores. Fazemos revisões de código há algum tempo e a qualidade do código melhorou com o tempo.
No entanto, notei recentemente que alguns desenvolvedores estão solicitando mais análises de código do que outros. Receio que seja por causa de sua atitude flexível.
Na minha opinião, não é assim que as revisões de código devem ser feitas: toda a equipe deve ser responsável por isso e os revisores de código não devem ser escolhidos por sua disposição em aceitar facilmente alterações.
Como você lida com esse problema em sua equipe?
Você estabeleceu regras para escolher revisores de código?
Você acha que os revisores de código devem ser recompensados pelo tempo que passam fazendo (boas) análises de código? E como eles devem ser recompensados?
Obrigado por suas respostas / idéias.
fonte
Respostas:
Não escolhemos revisores.
Em nossa equipe:
As revisões de código não são atribuídas, as pessoas as buscam quando funciona para elas. O entendimento é que não podemos divulgar histórias através do pipeline. Ocasionalmente, alguém mencionará que está esperando um CR na fila, mas é isso.
Eu gosto desse modelo, ele permite que as pessoas escolham o que podem e evita "dar emprego às pessoas".
fonte
Introduza uma regra na qual um bug possa ser atribuído para correção, não apenas para aqueles que confirmaram a alteração, mas apenas para quem a revisou. Isso deve criar uma perspectiva correta para a revisão do código.
Quanto a,
Bem, eu não tenho certeza de como geralmente os desenvolvedores são recompensados por fazer seu trabalho, exceto apenas recebendo um salário e se orgulhando do que fizeram. Mas como a revisão do código faz parte do trabalho deles, o revisor deve ter tempo para a revisão e compartilhar o crédito de alguma forma.
fonte
O principal problema que você tem não é técnico, mas algumas ferramentas podem diminuir a quantidade de esforço que as revisões de código exigem. Existem alguns desafios a serem superados:
Isso não quer dizer que você não possa usar o SubVersion ou outras ferramentas (como a Fisheye) para ajudar, mas a integração incorporada ao pipeline do Git com ramificações de recursos realmente torna o trabalho menos trabalhoso.
Fora das ferramentas, você precisa olhar para mais desafios sociais:
Também pode valer a pena verificar que tipos de tarefas estão sendo revisadas pelo código pelas pessoas mais envolvidas. Eles podem estar recebendo todas as críticas fáceis, o que torna as coisas mais dolorosas para todos os outros.
fonte
Uma boa idéia é fazê-lo em rodízio - você escolhe alguém que fez o menor número de revisões para o seu código. Com o tempo, todos os membros da equipe deveriam ter feito aproximadamente um número igual de revisões. Também espalha o conhecimento.
Obviamente, haverá exceções ocasionais, como feriados, onde haverá picos e vales.
Não deve haver distinção entre juniores e seniores / leads. As revisões de código devem ser realizadas para o código de todos - independentemente da idade deles. Reduz o atrito e ajuda a compartilhar diferentes abordagens.
Se você ainda estiver preocupado com a qualidade das revisões, considere a introdução de um conjunto de padrões mínimos para a aprovação de uma revisão de código. O que você inclui depende inteiramente de você, mas algumas coisas que você pode querer considerar são: cobertura de código, testes de unidade, remoção de código comentado, métricas, comentários suficientes, qualidade de construção, princípios do SOLID, DRY, KISS etc.
Quanto a incentivar revisões de código, o código de qualidade é a recompensa. Temos certeza de que trabalhamos em bases de código abaixo do ideal, em que a dor poderia ter diminuído consideravelmente se outro desenvolvedor tivesse dado o código uma vez desde o início e sugerido mudanças construtivas.
fonte
Parece que a equipe carece de um processo formal para revisões de código.
Não estou falando de criar um documento do Word com 350 páginas, mas apenas alguns pontos simples sobre o que o processo implica.
Os bits importantes:
Defina um conjunto principal de revisores. Nenhuma declaração geral. Nomeie pessoas.
Esses devem ser seus desenvolvedores sênior.
Exija que mais de um revisor principal assine a revisão.
Identifique pelo menos 1 outro revisor que não seja o núcleo, a cada sprint ou versão, que seja um revisor temporário. Exija sua aprovação em todas as revisões de código durante esse período.
O item 3 permite que os outros desenvolvedores alternem para o grupo principal de revisores. Algumas semanas eles gastam mais tempo com críticas do que outras. É um ato de equilíbrio.
Quanto a recompensar as pessoas? Muitas vezes, reconhecer o esforço que uma pessoa está fazendo durante a revisão de código na frente de toda a equipe pode funcionar, mas não se estresse com isso.
Em caso de dúvida, defina o processo e diga à equipe que eles precisam cumpri-lo.
E há uma última coisa que você pode tentar - por mais controverso que seja: deixe o @ # $% atingir o ventilador, se eu puder usar um idioma.
Deixe a equipe falhar, porque o processo de revisão de código não está sendo seguido. A gerência se envolverá e as pessoas mudarão. Essa é realmente apenas uma boa ideia nos casos mais extremos em que você já definiu um processo e a equipe se recusou a cumpri-lo. Se você não tem autoridade para demitir pessoas ou discipliná-las (como a maioria dos desenvolvedores líderes não ), precisa envolver alguém que possa fazer essas coisas.
E não há nada como falha em fazer as coisas mudarem. Apesar do que as pessoas possam dizer, você pode dirigir o Titanic - mas não antes que ele atinja o burg de gelo.
Às vezes, você só precisa deixar o Titanic acertar no gelo.
fonte