O que é uma mentalidade útil ao realizar uma revisão formal de código

Nossa equipe começou recentemente a realizar revisões de código em cada check-in.

Como líder da equipe, estou tentando encontrar um equilíbrio entre fornecer muitas sugestões, incomodar os desenvolvedores e diminuir a produção das equipes e deixar de lado o código que eu teria escrito de maneira diferente.

Existe alguma evidência, estudo ou orientação de fontes conhecidas que sugira uma abordagem útil?

Lembre-se dos objetivos gerais: no final, apenas o software em funcionamento é importante

A revisão por pares e a revisão do código de check-in têm o objetivo de melhorar a qualidade . Mas não há nada pior para a qualidade do que um desenvolvedor desmotivado. Como líder de equipe, seu papel não é endossar o código como algo que você poderia ter escrito, mas promover o trabalho em equipe e garantir o resultado geral.

Defina um escopo claro para sua revisão

Lembre-se: não é o seu código, mas o código da equipe. Portanto, concentre-se em coisas que podem levar a resultados errados.

• Não desafie a maneira como o desenvolvedor optou por atender aos requisitos, a menos que você tenha certeza de que não funcionará (mas já deveria ter falhado nos testes, não?)

• Não desafie o desempenho ruim, a menos que exista uma medida que mostre onde está o problema. Otimização prematura é a raiz de todo o mal ;-)

• Se você acha que uma estrutura de design ou software é desafiadora, pergunte-se por que ela não foi capturada antecipadamente! O código já escrito é caro para reescrever. Se isso acontecer, é hora de revisar suas práticas de desenvolvimento de software e trabalho em equipe pelo menos tanto quanto o código.

• abordar a conformidade com os padrões de codificação estabelecidos. É o tópico mais irritante para discutir, tanto para o revisor como para o revisado. Quando todos concordam em usar nomes de classe com letras maiúsculas em sua equipe e um cara não tem uma aula, é uma questão de gosto? Ou da eficácia e risco do trabalho em equipe?

A propósito, se você acha que não vale a pena discutir um padrão de codificação, remova-o de acordo com seus padrões e não perca tempo e energia com ele.

Desenvolver liderança: o lado humano da revisão

Como líder de equipe, você pode encontrar aqui uma oportunidade de desenvolver a si e a sua equipe, além da formalidade de um controle de qualidade:

• As revisões de código são muito mais agradáveis ​​para todos, se houver uma troca verdadeira. Dê ao seu desenvolvedor a oportunidade também de mostrar suas habilidades (e sim, talvez você possa aprender algo novo).
• Ter ouvidos abertos a críticas sobre escolhas de design ou padrões existentes. Às vezes, as pessoas conseguem lidar melhor com essas frustrações, apenas porque podem falar sobre isso.
• Treine seus juniores: não hesite em dar conselhos ou refatorar orientações para a próxima iteração. Não faça isso com idosos: em outro mundo, seu respectivo papel poderia ter mudado.

Aproveite outras práticas

Há algumas coisas que você pode evitar na revisão de código:

• O uso de um analisador de código estático em sua cadeia de construção pode automatizar a localização de bugs comuns ou construções não portáteis, muito antes da revisão por pares. Algumas ferramentas podem até verificar alguns dos seus padrões de codificação .
• Se você possui padrões sobre o layout do código, use um formatador de impressão bonita ou similar para formatar o código automaticamente, conforme necessário. Nunca gaste tempo com algo que um software poderia fazer por você melhor e sem discutir :-)
• Finalmente, a qualidade não é garantida apenas pela revisão, mas também pelos testes. Se você ainda não usa o TDD , pense independentemente da revisão do código.

Como desenvolvedores que somos, a mentalidade deve permanecer sempre aberta e cética ao mesmo tempo.

Aberto, porque não sabemos quando um desenvolvedor pode nos surpreender, e cético em relação a nossas próprias idéias, porque muitas vezes esquecemos que na engenharia de software não há uma única maneira correta de implementar uma solução. A lógica por trás de nossas soluções pode fazer sentido para nós e não para os outros. Por trás de um cheiro de código, poderia haver uma ótima idéia. Talvez o desenvolvedor não tenha encontrado a maneira de expressá-lo corretamente.

Devido a nós (seres humanos) sermos péssimos em nos comunicar, não faça suposições falsas, esteja disposto a perguntar ao proprietário do código sobre o código que você está revisando. Se ele / ela falhou em codificar a idéia sob os padrões da empresa, como desenvolvedor-chefe esteja disposto a orientá-lo também.

Aqui a abordagem subjetiva. A abordagem objetiva, IMO, está muito bem explicada nesta questão .

Além do link acima, o conjunto de objetivos a serem atingidos (manutenibilidade, legibilidade, portabilidade, alta coesão, acoplamento solto etc.) não são necessariamente os Dez Mandamentos. Você (a equipe) deve poder adaptar esses objetivos a um ponto em que o equilíbrio entre qualidade e produtividade torne o trabalho confortável e "habitável para desenvolvedores".

Eu sugeriria o uso de ferramentas de análise de código estático para medir o progresso da qualidade de acordo com esses objetivos. Ferramentas como o SonarQube nos fornecem Portões de Qualidade e Perfis de Qualidade que podem ser personalizados de acordo com nossas prioridades. Ele também fornece um rastreador de problemas, no qual os desenvolvedores podem ser direcionados a problemas relacionados a cheiro de código, bugs, práticas duvidosas etc.

Esse tipo de ferramenta pode ser um bom ponto de partida, mas como eu disse, mantenha-se cético. Você pode achar que algumas regras no Sonar não têm sentido para você; portanto, fique à vontade para ignorá-las ou removê-las do seu perfil de qualidade.

A intromissão no código do desenvolvedor para alterações cosméticas desmotivará o desenvolvedor, mas em circunstâncias absolutas, isso deve ser feito. O líder precisa encontrar o equilíbrio entre fornecer uma útil revisão de código e aprender a deixar de lado pequenas falhas. https://blog.smartbear.com/sqc/for-the-new-team-lead-the-first-six-things-you-should-know/

Algumas coisas a ter em mente:

1. É tanto sobre psicologia quanto sobre tecnologia, então não há regra de ouro aqui.
2. O que é sobre as pessoas não é apenas sobre conhecimento, mas também sobre cultura e posição na hierarquia.
3. Se este é um jogo "longo" (empresa estável e estabelecida), uma equipe bem integrada, onde as pessoas confiam umas nas outras, geralmente tem um valor mais alto do que o código em análise. Não deve ser usado para forçar coisas que não são absolutamente necessárias para prosseguir. O diabo está nos detalhes ...
4. Se este é um jogo "curto" (projeto paralelo, pesquisa e desenvolvimento, muitos freelancers em um grupo), os custos de RC geralmente superam as aventuras que vêm sendo feitas. E a atitude deve ser "apenas faça wok"

Existem apenas duas coisas que importam.

1. Existem testes automatizados para todos os requisitos?
2. Todos eles passam?

Tudo o resto é cosmético e deve ser discutido sobre a cerveja, e não aplicado como um portão.

Se você seguir essa visão, ela o limitará a uma área de foco estreita.

Os requisitos são bons? O que idealmente você deve saber antes de iniciar a tarefa, ou seja, desempenho, segurança etc., todos devem estar lá

Os testes são bons? Quaisquer casos extremos perdidos, eles estão testando bem o requisito, etc. Finalmente: você pode escrever um teste para um requisito existente, mas que falhará?