Quem deve fazer revisões de código?

Na minha empresa, principalmente o arquiteto faz revisões de código. Ele é um cara de software muito experiente e inteligente, então é muito bom nisso. Quando os desenvolvedores fazem as revisões de código, eles também não fazem isso pela metade. Tentamos dar aos desenvolvedores mais revisões de código, mas a qualidade delas não era boa. Usamos Scrum como metodologia de desenvolvimento.

No entanto, com o sistema atual, existem dois problemas:

1. O arquiteto se torna um gargalo

2. Os desenvolvedores não se responsabilizam pela qualidade do código e da arquitetura (o que leva a todos os tipos de problemas).

Como podemos resolver esses problemas? Devemos mudar quem revisa o código?

Os desenvolvedores devem fazer revisões de código. Eles devem fazer revisões de código, porque devem conhecer o código, os padrões e práticas de estilo da empresa. Ao fazer com que outra pessoa faça revisões de código, você está dizendo aos desenvolvedores que não é responsabilidade deles garantir que o código atenda aos padrões da empresa.

Se você acha que eles precisam de treinamento para fazer revisões de código, obtenha-os. Dada a sua situação atual, você pode solicitar que um desenvolvedor faça a revisão do código e, em seguida, faça o comentário do arquiteto - peça ao desenvolvedor que envie a revisão ao arquiteto para aprovação antes de enviá-la ao remetente.

Nessa situação, o que você precisa é que o conhecimento desse desenvolvedor experiente ajude o restante da equipe a crescer. A qualidade de uma equipe não é definida pelas habilidades do melhor desenvolvedor; é definido pelas habilidades dos piores. Você pode tentar coisas como:

• Revisões colaborativas. Isso funcionou muito bem na minha última equipe. Colocamos toda a equipe em uma sala com um projetor e começamos a revisar alguns itens. Talvez no início o arquiteto seja o que guia a revisão, mas em algumas semanas (reservamos uma ou duas horas toda sexta-feira) toda a equipe começa a conversar e entender os principais conceitos que atualmente apenas o arquiteto parece conhecer.

• Programação em pares. Para mim, esta é a melhor ferramenta para disseminar conhecimento em equipe.

Embora eu possa entender o motivo de o arquiteto de sistema / software assinar todas as alterações / confirmações, os desenvolvedores de software devem poder fazer revisões sem envolver o arquiteto - exceto a arbitragem.

Meus procedimentos de revisão [*] preferidos são:

• Agrupe alterações por requisito / problema.
• Convide todos os desenvolvedores, o arquiteto do software e o autor do requisito / problema a revisar. (Eles não são todos obrigados a fazer uma revisão.)
• Considere uma revisão concluída quando:
  • Dois desenvolvedores revisaram.
  • Todos os comentários são respondidos. (Possivelmente pedindo que o arquiteto do software tome uma decisão.)
  • Um dia útil passou sem discussão adicional (ou todas as partes convidadas foram revisadas).

Portanto, minha resposta curta para sua pergunta é: Os desenvolvedores devem fazer revisões de alterações.

[*] Infelizmente, nem sempre é assim que os projetos dos quais participo operam.

Gosto da prática de revisões ocasionais de código de equipe, que incluem toda a equipe, os arquitetos, mas depois várias e muitas análises de código entre dois ou três membros da equipe.

Se for um código realmente complicado ou sensível, aliste o arquiteto ou os membros seniores da equipe.

Honestamente, porém, parece meio ridículo ter um arquiteto fazendo revisões de código. Ele deveria fazer revisões de design ou ocasionais revisões de código informalmente para compartilhar seus conhecimentos. A equipe de engenharia deve assumir a responsabilidade pelo código. Se houver problemas, eles melhorarão com o tempo.

Eu concordo que, se apenas uma pessoa fizer uma crítica, o resto dos caras provavelmente dirá "Não sei, parece funcionar, mas deixe esse cara inteligente descobrir se está tudo bem ou não". Eu posso pensar no seguinte:

• torne seu código público para que todos possam ver no que estão trabalhando; coloque nomes no início de cada arquivo que contém código; talvez as imprima e as imprima no banheiro ou em qualquer lugar que você sentir
• programação em pares; com outro cérebro ao seu lado, você pensará duas vezes antes de nomear sua variáveli
• pegue seu zelador e explique a ele como essa herança funciona (oh, sim, não funciona). Explicar o seu código para outra pessoa ajuda. Talvez compile, talvez faça as coisas certas, mas você realmente não entendeu o porquê. Agora é sua chance
• tenha um conjunto de diretrizes e faça com que todos as sigam; qualquer que seja a diretriz, é melhor do que nenhuma diretriz