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

15

Nossa equipe começou recentemente a realizar análises de código em cada check-in.

À medida que a equipe lidera, estou tentando encontrar um equilíbrio entre fornecer muitas sugestões, desenvolvedores irritantes e diminuir a saída das equipes, e deixar ir o código que eu teria escrito de forma diferente.

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

    
por Kye 24.06.2017 / 09:13
fonte

5 respostas

15

Tenha em mente os objetivos gerais: no final, somente os softwares de trabalho são importantes

A revisão por pares e a revisão do código de check-in têm como objetivo 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 sozinho, mas promover o trabalho em equipe e garantir o resultado geral.

Defina um escopo claro para sua análise

Tenha em mente: não é o seu código, mas o código da equipe. Então, concentre-se em coisas que poderiam levar a resultados errados.

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

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

  • Se você encontrar um design ou uma estrutura de software a ser desafiada, pergunte-se por que não foi pego antecipadamente! O código já escrito é caro para reescrever. Se isso acontecer, é hora de rever seu desenvolvimento de software e práticas de trabalho em equipe, pelo menos tanto quanto o código.

  • aborda a conformidade com os padrões de codificação estabelecidos. É o tópico mais irritante para discutir tanto para o revisor quanto para o revisado. Quando todos concordaram em usar nomes de classe capitalizados em sua equipe e um cara tem uma classe sem, é uma questão de gosto? Ou de eficácia e risco de trabalho em equipe?

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

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

Como líder de equipe, você pode encontrar aqui uma oportunidade de desenvolver a si mesmo e 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 real. Dê ao seu desenvolvedor a oportunidade de também mostrar suas habilidades (e sim, talvez você possa aprender algo novo).
  • Tenha um ouvido aberto para críticas sobre escolhas de design ou padrões existentes. Às vezes as pessoas podem lidar melhor com essas frustrações, só 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 os seniores: em outro mundo, seu papel poderia ter mudado.

Aproveite as 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 na sua cadeia de criação pode automatizar o encontrar bugs comuns , ou construções não portáteis, muito antes da revisão por pares. Algumas ferramentas podem até mesmo verificar alguns dos seus padrões de codificação .
  • Se você tiver padrões sobre o layout de código, use um pré-compromisso -print ou formatadores semelhantes para formatar o código conforme exigido automaticamente. 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 por testes. Se você ainda não usa o TDD , pense nele independentemente da revisão de código.
por 24.06.2017 / 12:30
fonte
3

Como desenvolvedores 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 sobre nossas próprias ideias, porque muitas vezes esquecemos que, na engenharia de software, não existe 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 fazer nenhuma para os outros. Por trás de um cheiro de código pode haver uma ótima idéia. Talvez o desenvolvedor não tenha encontrado a maneira de expressá-lo corretamente.

Devido a que nós (humanos) somos péssimos na comunicação, não façamos suposições falsas, desejamos perguntar ao dono do código sobre o código que você está revisando. Se ele / ela falhar em codificar a idéia sob os padrões da empresa, o desenvolvedor líder também estará disposto a guiá-lo.

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

Além do link acima, o conjunto de objetivos a serem atingidos (manutenibilidade, legibilidade, portabilidade, alta coesão, baixo acoplamento, etc.) não são necessariamente os Dez Mandamentos. Você (a equipe) deve ser capaz de adaptar esses objetivos a um ponto em que o equilíbrio entre qualidade e produtividade torna 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 portais de qualidade e perfis de qualidade que podem ser personalizados de acordo com nossas prioridades. Ele também nos fornece um rastreador de problemas, onde os desenvolvedores podem ser direcionados a problemas relacionados ao 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 são insignificantes para você, então sinta-se à vontade para ignorá-las ou removê-las de seu perfil de qualidade.

    
por 24.06.2017 / 13:34
fonte
2

A intromissão no código do desenvolvedor para mudanças estéticas desmotivará o desenvolvedor, mas em circunstâncias absolutas ele precisa ser feito. O líder precisa encontrar o equilíbrio entre fornecer uma revisão de código útil e aprender a soltar as deficiências menores. link

    
por 24.06.2017 / 09:33
fonte
1

Algumas coisas para ter em mente:

  1. É sobre psicologia tanto quanto sobre tecnologia, então não há regra de ouro aqui.
  2. O que é sobre pessoas não é apenas sobre conhecimento, mas também sobre cultura e posição na hierarquia.
  3. Se este for um jogo "longo" (empresa estável e estabelecida), a equipe bem integrada em que as pessoas confiam umas nas outras geralmente tem um valor maior 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 for um jogo "curto" (projeto paralelo, R & D, muitos freelancers em um grupo), os custos de CR muitas vezes superam os benefícios advindos da sua realização. E atitude deve ser "apenas fazer wok"
por 24.06.2017 / 11:32
fonte
-4

Existem apenas duas coisas que importam.

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

Tudo o mais é cosmético e deve ser discutido sobre a cerveja, em vez de ser imposto como um portão.

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

Os requisitos são bons? Qual idealmente você deve saber antes de iniciar a tarefa, ou seja, desempenho, segurança, etc, tudo deve estar lá

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

    
por 24.06.2017 / 09:53
fonte