Digamos que se trabalhe em uma empresa hipotética que possui vários desenvolvedores que raramente trabalham juntos em projetos e o chefe não acreditava que as revisões de código valessem o tempo e o custo.
Quais são os vários argumentos que poderiam ser apresentados nesse cenário que retratariam os benefícios da revisão de código? Além disso, quais são os possíveis argumentos contra a revisão de código aqui e como eles podem ser combatidos?
Respostas:
Se você precisa se justificar para coisas tão básicas, tem um problema maior.
Você é o especialista, sua equipe deve decidir quais práticas você usa. Talvez você deva começar a convencer seu chefe desse princípio muito importante.
Seu chefe é suposto para decidir O QUE fazer e, mais importante PORQUE fazê-lo. Você deve cuidar do COMO construí-lo
(isso não significa que você não pode sugerir o que e por que fazer as coisas na sua empresa, é claro). Um grande chefe deve incentivar seus funcionários a participar da estratégia da empresa)
No entanto, aqui está como eu vejo as revisões de código por pares:
Como a programação é um trabalho intelectual muito intenso, uma pessoa não pode garantir que tudo esteja perfeito. Portanto, a revisão de código garante que:
Todo mundo está tirando benefícios diretos disso:
A revisão de código pode familiarizar vários desenvolvedores com o mesmo código. Isto é uma coisa boa. E se o autor original decide desistir ou pior, algo ruim acontece com ele. Se revisões de código são feitas regularmente, outras pessoas podem assumir o controle rapidamente.
Os pares talvez consigam detectar possíveis erros ou problemas de desempenho durante a revisão do código. Isso reduz o controle de qualidade e o esforço de desenvolvimento. Isso pode compensar o custo adicional envolvido nas revisões de código.
Revisões de código promovem o compartilhamento de conhecimento. Os colegas podem dizer maneiras melhores ou alternativas de fazer as coisas. Eu mesmo aprendi muito com meus colegas através de revisões de código.
As revisões de código ajudam a reforçar as diretrizes de codificação seguidas pela equipe. Se a equipe não tiver um, isso precisará ser corrigido. O código deve ser escrito uma vez e lido várias vezes. As diretrizes de codificação são um passo em direção ao código legível. O código deve ser legível pelos pares. Qual a melhor maneira de fazer análises de código para garantir a legibilidade?
Muitas ótimas respostas aqui. Algumas coisas que eu acrescentaria:
Quando você precisa explicar o código para outra pessoa, geralmente no decorrer da explicação, o desenvolvedor pode perceber repentinamente que tem um bug. Eu já vi isso acontecer repetidas vezes, que o desenvolvedor para de parar e diz "oh, espere, isso está errado" antes que o revisor entenda a coisa suficientemente bem para ver o bug.
Saber que seu código será inspecionado por outra pessoa oferece a você mais incentivo para usar padrões de codificação (facilitando a manutenção) ou usar menos métodos "cowboy" que ninguém, exceto você (e às vezes nem você mesmo) jamais entenderá. Você não quer ficar envergonhado quando mostra seu código a outra pessoa, para fazer um trabalho melhor nele. Por causa do fator embaraçoso, deixa menos do código comentado com: "Não sei por que isso funciona, mas não mexa com ele". na base de código.
Desenvolvedores que precisam de supervisão ou treinamento mais extensos são facilmente identificados. Assim são os completamente incompetentes. Quanto mais cedo você encontrar e resolver problemas de desempenho, melhor será a equipe como um todo e maior será a qualidade do aplicativo. É bom descobrir essas informações antes de escolher o novo profissional que precisa de treinamento e atribuí-lo à parte mais difícil e crítica do seu aplicativo.
Às vezes, é apenas uma questão de corrigir uma percepção equivocada que poupará o mesmo erro em muitos outros lugares. Por exemplo, recentemente revisamos alguns SQL para relatórios complexos e descobrimos que vários de nossos novos desenvolvedores tinham o mesmo mal-entendido sobre onde encontrar uma informação específica no banco de dados (reconhecidamente, o local que eles escolheram parecia lógico, o que é um problema de design de banco de dados. também é necessário corrigir) que seria crítico para escrever corretamente todos os relatórios. Ao encontrar o problema e corrigi-lo nos primeiros relatórios que eles escreveram, evitou que o mesmo erro acontecesse no restante dos relatórios. E algo que os desenvolvedores mais antigos (em tempo de trabalhar aqui, não em idade) estavam tão acostumados que não acharam que fosse necessário explicar.
Os juniores podem aprender com o código mais sofisticado escrito pelos idosos (que tendem a entender melhor a captura de erros e casos extremos, por exemplo) e os idosos podem aprender com as novas técnicas usadas pelos juniores aos quais ainda não foram expostos.
Às vezes, as pessoas que trabalham em partes diferentes, mas relacionadas ao aplicativo, percebem que estão seguindo duas direções diferentes e mutuamente exclusivas. Opa, mais fácil de corrigir agora.
Não é tão fácil se infiltrar em valores codificados que mudarão ao longo do tempo apenas para que a coisa funcione agora. Isso evita muitos bugs futuros, como coisas que mudam no início de cada ano fiscal.
Às vezes, eu fiquei preso em como fazer algo e aprendi uma nova técnica que era exatamente o que eu queria ao revisar o código de outras pessoas.
Se você estiver familiarizado com o que os outros membros de sua equipe pensam (qual revisão de código ajudará a fornecer esse entendimento), será mais fácil solucionar problemas posteriormente, porque você começará com um entendimento de como Joe teria abordado esse tipo de problema. problema.
Além do compartilhamento de conhecimento mencionado pelos outros, encontre exemplos de erros encontrados durante uma revisão de código e meça quanto tempo eles levaram para corrigir - isso inclui o tempo gasto pesquisando o problema e liberando a versão corrigida, bem como o hora real de corrigir o erro.
Pegue esse custo, que provavelmente levará um esforço de pelo menos alguns dias, e compare-o com o tempo que você gastaria em uma revisão de código e atuando nos resultados.
Isso mostrará ao seu chefe que as revisões de código valem a despesa.
As revisões de código podem:
Contras
Se isso é verdade, por que sempre parecemos ter tempo para fazer as coisas duas ou três vezes para o mesmo cliente, mas nunca temos tempo suficiente para fazer as coisas direito da primeira vez.
Se você precisar fazer referência a um documento, não procurarei mais do que o estimado "Código Completo". Nele, o livro descreve quantos erros são detectados nos testes de unidade versus revisão por pares. É espantoso. Os testes de unidade, se a memória me servir bem, capturam apenas ~ 30% de todos os erros, enquanto as revisões formais por pares capturam ~ 70%.
Pegue essas informações, mostre a ele no livro e apele para o lado financeiro dele. Leva muito mais tempo e é muito mais caro permitir a passagem de bugs do que pegá-los mais cedo.
Que tal executar uma demo (um projeto do tipo "mickey mouse" de uma semana) executado em paralelo por duas equipes, uma usando revisão de código e a outra não.
No final da semana, avalie a qualidade do trabalho de cada equipe, tenho certeza de que os revisores de código serão melhores.
Do Construx de Steve Mcconnel O caso de negócios para melhores práticas de software e o LHF ( Low Hanging Fruit ) do desenvolvimento de software de software abordam isso. Deste último, "LHF que não será resistido pela alta gerência", lista Inspeções.
Ao apresentá-lo, foque na imagem maior.
Liste os benefícios (melhor código, menos erros, menos reescrições, etc.) e mencione a revisão de código como uma das técnicas que você recomendaria.
Gostaria de fazer parte de uma imagem maior de como criar software
Esteja preparado para trabalhar muito na promoção desses princípios.
Acima de tudo, não esperamos que a persuasão seja uma coisa "única e concluída".
Você deve construir o caso ao longo do tempo com calma e consistência. Quando você fica mais irritado com os bugs que seriam corrigidos por melhores técnicas, geralmente é o pior momento para defender seu caso, pois é mais provável que você seja emocional demais e menos racional. Isso pode parecer um tanto contra-intuitivo, mas é o que aprendi ao longo de 30 anos de programação. Obviamente sim.