Como lidar com nenhuma revisão de código em meu novo local quando venho dessa prática?

A equipe da minha nova empresa não possui um processo de revisão de código.

Eu venho de empresas com revisão de código como uma cultura obrigatória e, portanto, não me sinto confortável em confirmar meu código sem que ele seja revisto por alguém.

Acredito firmemente que a revisão de código é uma maneira de melhorar a qualidade e economizar tempo, pois detecta possíveis problemas anteriormente (note que não estou falando de programação em pares).

• Como posso mostrar que a revisão de código não é uma perda de tempo, mas uma economia de tempo?
• A revisão de código pode ser ignorada se você tiver testes de unidade?

A revisão de código pode ser ignorada se você tiver testes de unidade?

Mas por que?

O papel principal da revisão por pares não é detectar erros.

Sim, você pode identificar alguns bugs em potencial e códigos duvidosos, propensos a erros, isso geralmente acontece, mas, ocasionalmente, detectar alguns erros não significa que a revisão por pares é uma maneira confiável de excluir a presença de bugs. Longe disso. Não é a ferramenta certa para verificar a correção funcional da implementação.

A revisão de código reforça a manutenção do código , no entanto. Exigirei que o código seja limpo e compreensível (não apenas para o autor) antes de entrar em produção.

A presença de testes de unidade é completamente ortogonal a isso. Você pode ter 100% de cobertura de código e todos os testes aprovados para obter um código totalmente incompreensível.

A revisão de código também serve para familiarizar outros desenvolvedores com o seu trabalho, para que eles saibam o que é o que é capaz de captar a partir daí ou lidem com relatórios de erros durante as férias, etc. Saber o que você fez imediatamente pode ajudá-los faça seu trabalho bem - mantenha a base de código consistente (siga padrões e convenções semelhantes em todo o aplicativo) ou evite a duplicação de código.

Em um esquema mais amplo, também se aprende e cresce como desenvolvedor lendo o código de outras pessoas.

Os testes de unidade dificilmente podem substituir qualquer um deles. Sim, se eles são bem escritos, eles lêem como documentação, e devemos nos esforçar para isso. Mas, novamente, isso não é mutuamente exclusivo na realização de uma revisão por pares, pelo contrário - todas as vantagens da revisão por pares ainda são verdadeiras, o fato de seus colegas terem alguns bons testes de unidade para analisar só tornará o processo de revisão mais fácil e ainda mais benéfico ao invés de redundante.

Existem estudos e estatísticas mostrando que a revisão de código não é uma perda de tempo, mas uma economia de tempo?

Eu não conheço nenhum. Também é difícil conduzir esses estudos, porque você precisaria de duas equipes com uma tarefa de complexidade igual e realista para realizar, onde uma usa revisões de código e a outra não. Você provavelmente precisaria que eles resolvessem o mesmo problema, o que significa jogar muito dinheiro pela janela. E você precisaria repetir o experimento com frequência suficiente para obter relevância estatística, o que aumentaria esse dinheiro jogando em ordens de magnitude.

Se você apenas mede a eficiência de empresas que usam análises de código em comparação com empresas que não o fazem, não é apenas claro como medir a eficiência, mas também qual é a causa real. As revisões de código fazem parte de uma cultura maior. Qual parte realmente torna a equipe mais eficiente é difícil de dizer (e pode muito bem depender da natureza da equipe ou do projeto). Ou a presença dessa cultura pode significar simplesmente que a empresa é menor ou mais jovem, cada uma das quais tem muitos efeitos. Ou pode ser que a disposição de se submeter a revisões de código impeça ou promova uma distância saudável do seu ego;)

Mas não se esqueça: você tem sua própria experiência para aproveitar. É parte do motivo pelo qual eles te contrataram. Portanto, se você realmente acredita que pode aumentar a eficiência (e sua equipe realmente sofre de falta dela), comunique isso claramente.

A revisão de código pode ser ignorada se você tiver testes de unidade?

Não. Se você acredita na importância dos testes, na verdade seus testes devem ser a primeira coisa a ser revisada. E se eles não fizerem sentido? Ou se a cobertura é ruim? Ou se eles testam a implementação em vez do comportamento?

Retirado de alguns slides aleatórios que encontrei , mas os dados concretos vêm do livro Code Complete de Steve McConnell:

As revisões de código são úteis?

"Acredito que as revisões de código por pares são a maior coisa que você pode fazer para melhorar seu código"

Jeff Atwood, da Coding Horror, em http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html

---

"As inspeções individuais geralmente capturam cerca de 60% dos defeitos, o que é mais alto do que outras técnicas, exceto prototipagem e testes beta de alto volume".

Steve McConnell, Code Complete 2nd Edition, página 485

Esse número de 60% vem do artigo do IEEE de Shull et al 2002, O que aprendemos sobre o combate a defeitos, que contém a seção intitulada:

"Revisões pelos pares capturam 60% dos defeitos"

Disclaimer: Esta resposta é a minha experiência pessoal :)

Fiz experiências muito ruins com as revisões de código que mantemos. Porque geralmente temos apenas um revestimento ou menos e não há muito o que revisar.

Mas em projetos reais eu fiz boas experiências, no meu exame, meu instrutor revisava meu código regularmente e isso me ajudou muito a encontrar alguns erros que cometi com muita frequência, que não faço mais.

Então, eu diria que depende muito do que você está fazendo, de quantas pessoas você é etc.

Além disso, o risco de que suas visualizações de codificador terminem em uma guerra não é subestimado.

Você pode pedir ao seu líder de equipe e / ou colega que revise seu código por pares, mesmo que as revisões de código não sejam feitas normalmente, talvez como parte de seu treinamento.

Verifique se o seu código está bem escrito e testado antes da revisão.

Quando eu era líder de equipe, eu costumava fazer revisões de código de novos funcionários, até (depois de um tempo) eu parava de encontrar bugs ou qualquer outra coisa para criticar o código deles e em que ponto deixava de fazer revisões de código com eles; isso aconteceria quando:

• Eles aprenderam os sistemas com os quais se relacionavam e não precisavam das minhas explicações
• Eles aprenderam a projetar e / ou testar seu código até que estivesse livre de erros antes que eu o visse.
• Eles aprenderam o suficiente sobre minhas diretrizes de estilo de codificação que eu consideraria seu código sustentável

As revisões de código têm vários propósitos:

• Localizando defeitos no código
• Transferência de conhecimento entre os membros da equipe

Eu acho que é bom fazer revisões de código de novos funcionários, mesmo que a equipe decida pular as revisões de código entre os membros experientes da equipe.

Não existe uma regra básica para que as revisões de código sejam feitas em qualquer software desenvolvido ... tudo depende do escopo do aplicativo, do tamanho do cliente e do tamanho da empresa. Por exemplo, se você estiver criando um aplicativo em que é um aplicativo simples, onde talvez não haja outras versões sendo implementadas no futuro, o teste de unidade é suficiente. Mas, novamente, a revisão de código entra em vigor quando você fala sobre o desempenho do aplicativo, no qual é necessário revisar o código para verificar se há alguma falha no código que poderia ter sido feita de uma maneira melhor para facilitar um desempenho mais rápido.

As revisões de código geralmente são feitas quando há uma equipe de mais de 2 desenvolvedores e um líder técnico em que o líder técnico deseja garantir a qualidade do aplicativo e garantir que os padrões de código sejam seguidos para dimensionar o aplicativo para aprimoramentos futuros e atualizá-lo para diferentes próximas versões.

Por exemplo, agora temos muitas plataformas de código aberto CMS e essas plataformas lançam atualizações de tempos em tempos para aprimorar os recursos da plataforma, imagine um desenvolvedor usando uma dessas plataformas e não seguiu os padrões de código como codificação embutida nos arquivos principais, escrevendo aplicativos código nos arquivos de modelo e, se esse código entrar em produção e mais tarde, quando o cliente desejar atualizar a plataforma para uma nova versão, ele nunca será atualizado, a menos que a codificação seja refeita conforme os padrões de código dessa plataforma. Aqui, torna-se um problema sério a liberação do código para produção sem que seja feita a revisão do código.

Então, eu diria que fazer revisões de código antes do lançamento é uma obrigação para qualquer empresa de software profissional e as exceções podem ser apenas para aplicativos pessoais / de pequena escala, nos quais o desenvolvedor é um programador muito experiente e tem experiência com ele.

As revisões de código têm vantagens que não advêm do próprio processo de revisão: sempre há um dilema para obter código de alta qualidade, mas criado em pouco tempo. Sem revisões de código, você fica por conta própria, portanto pode sacrificar a qualidade por fazer o código em pouco tempo. Com as revisões de código, existe esse revisor que não deixa você com baixa qualidade de código - exatamente o que você deseja, sendo forçado a gastar tempo para obter código de qualidade, o que você queria em primeiro lugar e qual você sabe que isso acabará economizando tempo, pois cada hora gasta em escrever um código melhor é economizada em duas horas na depuração (ou mais).

Sem revisões de código, você fica por conta própria; portanto, é sua responsabilidade manter a alta qualidade do código. Uma solução simples é revisar todas as alterações feitas por você e corrigir coisas que não atendem aos seus padrões de qualidade.

Isso também evita situações horríveis em que as revisões de código levam a conflitos de egos - a situação em que o programador A usaria o método X, enquanto B usaria o método Y, portanto, se A escreve o código que usa o método X, o revisor B insiste no método Y, então A reescreve o código usando o método Y, enquanto que se B tivesse escrito o código e A revisasse exatamente o contrário.

Se você é um defensor das revisões de código, receio que não haja substituto real. O caso infeliz e estereotipado é um local de trabalho que não faz revisões de código porque (A) eles não estão familiarizados com a prática e / ou (B) eles não querem dedicar tempo e esforço para obter uma revisão de código sistema em vigor.

Basicamente, para conseguir o que deseja aqui, você precisa de uma mudança na cultura do local de trabalho - e isso nunca é simples ou fácil. Não se esqueça de que, mesmo que seu local de trabalho esteja 100% convencido de que as revisões de código são excelentes e desejam adotá-las, a mudança para a nova maneira de trabalhar ainda exigirá um investimento significativo de tempo, energia e produtividade. Esse investimento deve compensar-se - mas você precisa ter um buy-in para o investimento, não apenas o pagamento. Veja o vídeo de Roy Osherove "Teste de Unidade e TDD - Como Fazer Acontecer" - os desafios de adotar revisões de código são muito semelhantes aos de adotar testes de unidade.

Enquanto isso, faça o que puder para obter o máximo que puder:

• Se houver outros desenvolvedores que veem o valor das revisões de código, tente revisar um ao outro, mesmo informalmente.
• Se você tem um mentor ou algum desenvolvedor responsável por seu treinamento, explique a ele o valor que você vê nas revisões de código e pergunte se eles estariam dispostos a revisar seu código, pelo menos ocasionalmente.
• Diga ao seu gerente que você deseja revisar o código de outras pessoas, pois isso ajudará você a entender melhor o sistema.
• Se em algum momento você se tornar um líder de equipe, instale revisões de código localmente, apenas para sua equipe.

Um dos principais benefícios de qualquer uma dessas opções é que, se você conseguir mantê-las com o tempo, os desenvolvedores ao seu redor começarão a perceber as revisões de código. Você demonstrará efetivamente como as revisões de código podem ser integradas à cultura existente - e isso abre caminho para que a cultura comece a mudar. As revisões de código ajudam , portanto, se você conseguir demonstrar isso em pequena escala, isso abrirá o caminho para que outras pessoas - e a cultura como um todo - sigam o seu exemplo.

Pare de se preocupar com isso - seu novo empregador simplesmente não se importa com as revisões de código. Aprenda a confiar um pouco em suas próprias habilidades sem que alguém lhe diga que não há problema em verificar o código que você escreveu. Você aprenderá em breve a viver sem o processo entediante que está revendo o código de outras pessoas.

Siga as diretrizes de estilo (ou apenas o estilo) que todo mundo usa. Use sua experiência para decidir o que precisa ser comentado, quais convenções de nomenclatura usar e assim por diante.

Em seguida, teste tudo antes de fazer o check-in. O mais importante é que funcione corretamente.

Se o seu novo empregador não gostar da ideia de revisão de código, talvez seja porque ele tenha uma associação negativa com as metodologias antiquadas de tipo de comando e controle e esteja buscando um conjunto de práticas mais modernas e ágeis. Nesse caso, eles podem ser mais abertos à idéia de programação em pares, que oferece muitos dos mesmos benefícios, e são amplamente considerados como uma prática moderna e mais dinâmica.