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?
code-reviews
jparkcool
fonte
fonte
Respostas:
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.
fonte
Peer review doesn't even attempt to tackle this important aspect- bem, sim, mais ou menos. Até certo ponto. Costumo encontrar-me apontando por exemplo. "parceiro, você está efetivamente repetindo a mesma lógica aqui, e isso é uma bomba. Um dia isso vai mudar nesse outro lugar e vamos esquecer de atualizá-la aqui ..."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.
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?
fonte
return true;.Retirado de alguns slides aleatórios que encontrei , mas os dados concretos vêm do livro Code Complete de Steve McConnell:
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:
fonte
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.
fonte
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:
As revisões de código têm vários propósitos:
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.
fonte
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.
fonte
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.
fonte
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:
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.
fonte
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.
fonte
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.
fonte