Como introduzir gradualmente revisões de código?

Sou líder de uma equipe com meia dúzia de engenheiros seniores. Eu acredito muito que nos beneficiaria muito em fazer revisões de código por todos os motivos padrão. Não necessariamente a cada mudança, mas pelo menos um fluxo constante de análises em segundo plano. Então as pessoas, pelo menos, veem as mudanças dos outros e começam a falar sobre elas.

Existe uma boa maneira de apresentar resenhas? Sinto uma grande relutância da equipe, porque é apenas mais uma coisa a fazer, e as conversas podem ser dolorosas. Sinto que a revisão de todas as alterações não é iniciada, pelo menos como um primeiro passo. Gostaria que as pessoas entrassem no ritmo e na prática de fazer revisões com baixa frequência primeiro antes de aumentar a quantidade.

Alguém introduziu com sucesso as revisões de código gradualmente? Quão? Já pensei em exigir análises de arquivos ou bibliotecas "quentes". Ou escolhendo aleatoriamente. Ou eu, escolhendo as "opções" de revisão obrigatória. Ou é o único caminho a percorrer e fazer todas as mudanças?

Este não é um problema de ferramentas ou processos. É sobre cultura. Você descreve uma equipe composta por pessoas sensíveis às críticas e protetoras de seu próprio trabalho. É muito, muito comum. Mas não é profissional.

Meu conselho é começar a liderar pelo exemplo. Ofereça seus commits para revisão. Seja aberto ao solicitar que as pessoas destacem os problemas em sua abordagem. Seja receptivo ao feedback. Não fique na defensiva, mas explore as razões por trás do feedback e chegue a um acordo sobre as ações em equipe. Incentive uma atmosfera de diálogo aberto. Encontre um campeão ou dois em sua equipe que também estejam dispostos a fazer isso.

É trabalho duro.

O primeiro passo seria procurar alguém e dizer "ei, você revisaria meu código?". Seja a mudança que você deseja ver na sua organização. Se você não conseguir encontrar um único indivíduo disposto a fazê-lo, não poderá convencer toda a equipe. Se vocês dois tiverem algum sucesso, reporte à equipe.

Depois de encontrar alguém para rever o seu código, pergunte se eles se importam se você rever alguns dos seus códigos. Expresse-o como uma oportunidade de aprendizado para você e não como uma oportunidade para eles melhorarem seu código.

Como líder de equipe, o maior valor que recebo do processo de revisão de código é a consciência do que está acontecendo. Eu gosto de ter a chance de ver todas as alterações, mesmo que eu não tenha nenhuma alteração ou sugestão para o desenvolvedor. Eu chamo esses "comentários de conscientização". Posso transformá-los em menos de 30 minutos, para que não haja gargalos.

Eu sugiro que você comece com isso. Defina o processo de envio da revisão de código (é bastante simples se você usar o TFS) e envolva todos no envio de seus conjuntos de alterações para você (e somente para você) antes de fazer o check-in. Diga a eles que é apenas para conscientização e ninguém vai criticar seu código.

Após uma ou duas iterações de revisões de conscientização, comece a convidar outros membros da equipe a revisar o código uns dos outros ... novamente, apenas para conscientização. Acredite ou não, isso por si só pode ser útil para a coesão da equipe e a uniformidade do código.

Depois de envolver toda a equipe, você provavelmente descobrirá que seus desenvolvedores simplesmente não resistem em fazer sugestões no código uns dos outros. Isso acontecerá de maneira natural e orgânica (os engenheiros não podem se ajudar!) Convide a equipe para discutir isso e elaborar diretrizes para oferecer feedback construtivo uns aos outros. Em seguida, defina-os. Parabéns, agora você está no modo de revisão de código completo!

Existe uma boa maneira de apresentar resenhas?

Provavelmente, existem várias maneiras boas, dependendo da sua equipe e dos benefícios que você espera obter das revisões, mas qualquer abordagem terá alguns recursos em comum:

• explique o que você espera: este é um novo processo para sua equipe, ou pelo menos uma alteração no processo existente; portanto, é justo informar à equipe por que você está instituindo a mudança, como espera que a equipe se beneficie e como você saberá se está funcionando.

• defina o processo: conduza as pessoas pelo processo que você deseja que elas sigam para revisar o código, discutir mudanças, etc., para que todos na equipe saibam como proceder.

• defina os critérios: apresente os tipos de mudanças que as pessoas devem e não devem chamar como necessitando de melhorias. Por exemplo, é bom ressaltar bugs e melhorias significativas de desempenho; os padrões de codificação, a legibilidade e as questões de manutenção devem ser observadas, mas não mencionadas; questões de gosto ou estilo pessoal devem ser deixadas em paz.

• discuta o comportamento: Saliente que o objetivo é melhorar o código e promover um entendimento comum que ajudará a equipe a escrever um código melhor em todo o quadro, para não constranger ninguém, acertar pontuações etc. As críticas devem ser objetivas e construtivas, nunca pessoais. Estabelecer algumas regras básicas pode ajudar a facilitar o escrúpulo em revisar o código.

• coloque-se em primeiro lugar: se você planeja ter críticas individuais ou de grupo, provavelmente é uma boa ideia passar pelas primeiras como um grupo. A primeira revisão deve ser do seu próprio código, para que outros membros da equipe possam ver que o processo não é tão ruim e que você está disposto a fazer isso sozinho.

Comece realizando uma reunião inicial para explicar todas as opções acima e abordar as preocupações dos membros da equipe. Acompanhe o email que documenta o processo.

Sinto uma grande relutância da equipe, porque é apenas mais uma coisa a fazer, e as conversas podem ser dolorosas.

Essas são duas preocupações distintas. Se você acredita que as análises serão úteis, precisará criar um cronograma para fazê-las. Certifique-se de que os membros da equipe entendam que a revisão é um trabalho como qualquer outra tarefa, não algo adicional que eles precisam fazer enquanto continuam a concluir outras tarefas na mesma proporção.

As reuniões de revisão do grupo devem ser lideradas por um facilitador que mantém a discussão em andamento, limita a duração da reunião e mantém as coisas construtivas. Isso deve ajudar bastante a evitar conversas dolorosas. Quando você estiver pronto para iniciar revisões individuais, esperamos que a equipe tenha adotado comportamentos que os ajudem a manter as coisas construtivas por conta própria.

Você também deve revisar o processo de revisão periodicamente. Reúna a equipe de tempos em tempos para discutir o processo: quão bem está funcionando, como pode ser aprimorado, quais práticas devem ser abandonadas etc. Dê à equipe a propriedade do processo e liberdade para experimentar coisas novas.

Uma maneira de fazer isso é realizar sessões de revisão de código após cada sprint e passar pelas alterações de todos, onde o código é projetado para uma espécie de tela grande para que todos da equipe possam participar. Quaisquer melhorias podem ser adicionadas como dívida técnica ao backlog.

Essa abordagem funciona, mas não é perfeita.

O objetivo final seria usar a solicitação pull para mesclar o código de volta ao mestre ou desenvolver o ramo onde cada linha de código deve ser revisada.