Após alguns sérios problemas de qualidade no ano passado, minha empresa introduziu recentemente revisões de código. O processo de revisão de código foi rapidamente introduzido, sem diretrizes ou qualquer tipo de lista de verificação.

Outro desenvolvedor e eu escolhemos revisar todas as alterações feitas nos sistemas antes de serem mescladas no tronco.

Também fomos escolhidos como "Líder Técnico". Isso significa que somos responsáveis ​​pela qualidade do código, mas não temos autoridade para implementar alterações no processo, reatribuir desenvolvedores ou reter projetos.

Tecnicamente, podemos negar a fusão, devolvendo-a ao desenvolvimento. Na realidade, isso termina quase sempre com o nosso chefe exigindo que seja enviado a tempo.

Nosso gerente é um MBA que se preocupa principalmente com a criação de uma programação dos próximos projetos. Enquanto ele está tentando, ele quase não tem idéia do que o nosso software faz do ponto de vista comercial, e está lutando para entender até as demandas mais básicas dos clientes, sem explicação de um desenvolvedor.

Atualmente, o desenvolvimento é feito nas filiais de desenvolvimento no SVN. Depois que o desenvolvedor pensa que está pronto, ele reatribui o ticket do nosso sistema de bilhetagem ao nosso gerente. O gerente então atribui a nós.

As revisões de código levaram a algumas tensões dentro de nossa equipe. Especialmente alguns dos membros mais velhos questionam as mudanças (ou seja, "sempre fizemos assim" ou "por que o método deve ter um nome sensato, eu sei o que ele faz?").

Após as primeiras semanas, minha colega começou a deixar as coisas deslizarem, para não causar problemas com os colegas de trabalho (ela mesma me disse que, depois que um relatório de bug foi arquivado por um cliente, que ela conhecia o bug, mas temia que o desenvolvedor ficaria bravo com ela por apontar isso).

Eu, por outro lado, agora sou conhecido por ser um idiota por apontar problemas com o código confirmado.

Não acho que meus padrões sejam altos demais.

Minha lista de verificação no momento é:

• O código será compilado.
• Há pelo menos uma maneira de o código funcionar.
• O código funcionará com a maioria dos casos normais.
• O código funcionará com a maioria dos casos extremos.
• O código lançará uma exceção razoável se os dados inseridos não forem válidos.

Mas aceito totalmente a responsabilidade da maneira como dou feedback. Eu já estou dando pontos acionáveis ​​explicando por que algo deve ser mudado, às vezes até perguntando por que algo foi implementado de uma maneira específica. Quando penso que é ruim, aponto que o teria desenvolvido de outra maneira.

O que me falta é a capacidade de encontrar algo para apontar como "bom". Eu li que alguém deveria tentar colocar más notícias em boas notícias.

Mas estou tendo dificuldades para encontrar algo que seja bom. "Ei, desta vez você realmente comprometeu tudo o que fez" é mais condescendente do que agradável ou útil.

Revisão de código de exemplo

Olá Joe,

Tenho algumas perguntas sobre suas alterações na classe Library \ ACME \ ExtractOrderMail.

Não entendi por que você marcou "TempFilesToDelete" como estático? No momento, uma segunda chamada para "GetMails" geraria uma exceção, porque você adiciona arquivos a ele, mas nunca os remove, depois de excluí-los. Eu sei que a função é chamada apenas uma vez por execução, mas no futuro isso pode mudar. Você poderia transformá-lo em uma variável de instância, então poderíamos ter vários objetos em paralelo.

... (Alguns outros pontos que não funcionam)

Pontos menores:

• Por que "GetErrorMailBody" aceita uma exceção como parâmetro? Perdi algo? Você não está lançando a exceção, apenas a repassa e chama "ToString". Por que é que?
• SaveAndSend Não é um bom nome para o método. Este método envia mensagens de erro se o processamento de uma mensagem estiver errado. Você poderia renomeá-lo para "SendErrorMail" ou algo semelhante?
• Por favor, não apenas comente o código antigo, exclua-o imediatamente. Ainda o temos em subversão.

Como encontrar coisas positivas em uma revisão de código?

Após alguns sérios problemas de qualidade no ano passado, minha empresa introduziu recentemente revisões de código.

Ótimo, você tem uma oportunidade real de criar valor para sua empresa.

Após as primeiras semanas, minha colega começou a deixar as coisas deslizarem, para não causar problemas com os colegas de trabalho (ela disse a si mesma, que depois que um relatório de bug foi arquivado por um cliente, que ela conhecia o bug, mas temia que o desenvolvedor ficaria bravo com ela por apontar isso).

Seu colega de trabalho não deve revisar o código se não conseguir informar aos desenvolvedores o que há de errado com o código. É seu trabalho encontrar problemas e corrigi-los antes que eles afetem os clientes.

Da mesma forma, um desenvolvedor que intimida os colegas de trabalho está pedindo para ser demitido. Eu me senti intimidado depois de uma revisão de código - eu disse ao meu chefe, e foi resolvido. Além disso, eu gosto do meu trabalho, por isso mantive o feedback, positivo e negativo. Como revisor, isso é por minha conta e não por mais ninguém.

Eu, por outro lado, agora sou conhecido por ser um idiota por apontar problemas com o código confirmado.

Bem, isso é lamentável, você diz que está sendo diplomático. Você pode encontrar mais elogios, se tiver mais a procurar.

Critique o código, não o autor

Você dá um exemplo:

Tenho algumas perguntas sobre suas alterações no

Evite usar as palavras "você" e "seu", digamos, "o" muda.

Perdi algo? [...] Por que é que?

Não adicione floreios retóricos às suas críticas. Também não faça piadas. Ouvi uma regra: "Se você se sentir bem em dizer, não diga, não é bom".

Talvez você esteja polindo seu próprio ego às custas de outra pessoa. Mantenha isso apenas para os fatos.

Eleve a barra dando um feedback positivo

Isso eleva a fasquia para elogiar seus colegas desenvolvedores quando eles atendem a padrões mais altos. Então isso significa a pergunta,

Como encontrar coisas positivas em uma revisão de código?

é bom e vale a pena abordar.

Você pode apontar onde o código atende aos ideais de práticas de codificação de nível superior.

Procure que eles sigam as melhores práticas e continuem aumentando. Depois que os ideais mais fáceis forem esperados de todos, você precisará parar de elogiá-los e procurar práticas de codificação ainda melhores.

Práticas recomendadas para idiomas específicos

Se o idioma suportar documentação em códigos, espaços para nome, recursos de programação orientados a objetos ou funcionais, você poderá chamá-los e parabenizar o autor por usá-los quando apropriado. Esses assuntos geralmente se enquadram nos guias de estilo:

• Ele atende aos padrões internos de guia de estilo de idioma?
• Ele atende ao guia de estilo mais autoritário para o idioma (que provavelmente é mais rigoroso do que interno - e, portanto, ainda é compatível com o estilo interno)?

Práticas recomendadas genéricas

Você pode encontrar pontos para elogiar os princípios genéricos de codificação, sob vários paradigmas. Por exemplo, eles têm boas unittests? As unittests cobrem a maior parte do código?

Olhe para:

• testes de unidade que testam apenas a funcionalidade do assunto - zombando da funcionalidade cara que não se destina a ser testada.
• altos níveis de cobertura de código, com teste completo de APIs e funcionalidade pública semanticamente.
• testes de aceitação e testes de fumaça que testam a funcionalidade de ponta a ponta, incluindo a funcionalidade que é zombada para testes de unidade.
• boa nomeação, pontos de dados canônicos para que o código seja SECO (não se repita), sem seqüências ou números mágicos.
• nomeação de variáveis ​​tão bem feita que os comentários são amplamente redundantes.
• limpezas, melhorias objetivas (sem trocas) e refatorações apropriadas que reduzem linhas de código e dívida técnica sem tornar o código completamente estranho aos escritores originais.

Programação Funcional

Se a linguagem é funcional ou suporta o paradigma funcional, procure estes ideais:

• evitando globais e estado global
• usando fechamentos e funções parciais
• pequenas funções com nomes legíveis, corretos e descritivos
• pontos de saída únicos, minimizando o número de argumentos

Programação Orientada a Objetos (OOP)

Se o idioma suportar OOP, você poderá elogiar o uso apropriado desses recursos:

• encapsulamento - fornece uma interface pública pequena e bem definida e oculta os detalhes.
• herança - código reutilizado adequadamente, talvez através de mixins.
• polimorfismo - interfaces são definidas, talvez classes básicas abstratas, funções escritas para suportar polimorfismo paramétrico.

no POO, também existem princípios SOLID (talvez alguma redundância para os recursos do POO):

• responsabilidade única - cada objeto tem uma parte interessada / proprietário
• aberto / fechado - não modificando a interface dos objetos estabelecidos
• Substituição de Liskov - subclasses podem ser substituídas por instâncias de pais
• segregação de interface - interfaces fornecidas pela composição, talvez mixins
• inversão de dependência - interfaces definidas - polimorfismo ...

Princípios de programação Unix :

Os princípios do Unix são modularidade, clareza, composição, separação, simplicidade, parcimônia, transparência, robustez, representação, menos surpresa, silêncio, reparo, economia, geração, otimização, diversidade e extensibilidade.

Em geral, esses princípios podem ser aplicados sob muitos paradigmas.

Seus critérios

Estes são muito triviais - eu me sentiria condescendente se elogiado por isso:

• O código será compilado.
• Há pelo menos uma maneira de o código funcionar.
• O código funcionará com a maioria dos casos normais.

Por outro lado, esses elogios são bastante altos, considerando o que você parece estar lidando, e eu não hesitaria em elogiar os desenvolvedores por fazer isso:

• O código funcionará com a maioria dos casos extremos.
• O código lançará uma exceção razoável se os dados inseridos não forem válidos.

Escrevendo regras para aprovação na revisão de código?

Essa é uma ótima idéia em teoria, no entanto, embora eu normalmente não rejeite o código por nomeação incorreta, vi uma nomeação tão ruim que rejeitaria o código com instruções para corrigi-lo. Você precisa poder rejeitar o código por qualquer motivo.

A única regra que posso pensar para rejeitar o código é que não há nada tão notório que eu o mantenha fora de produção. Um nome muito ruim é algo que eu gostaria de manter fora de produção - mas você não pode fazer disso uma regra.

Conclusão

Você pode elogiar as melhores práticas sendo seguidas sob vários paradigmas e, provavelmente, em todos eles, se o idioma os suportar.

Não se preocupe em escolher algo bom, a menos que seja um exemplo sólido e conciso e esteja diretamente relacionado ao problema em questão.

Não vou disfarçar - pelo que parece, você está lidando com pelo menos uma pessoa insegura com suas habilidades e está lidando com o desafio de seu trabalho de maneira imatura. Eles também são provavelmente ruins em seu trabalho - um bom desenvolvedor deve estar sempre disposto a refletir, aceitar críticas construtivas e estar aberto a mudanças de comportamento.

Agora que isso está no ar, vamos falar sobre você. Independentemente de se você acha que está sendo razoável, precisa ter cuidado extra com pessoas como essa para fazer a bola rolar. Descobri que a melhor maneira de lidar com essas pessoas é ter muito cuidado com a maneira como você expressa as coisas.

Verifique se você está culpando o código e não o autor . Concentre-se na questão em questão, e não na cocô que é sua base de código, que eles podem ter tido uma mão significativa na criação e seriam vistos como um ataque pessoal adicional. Escolha suas batalhas inicialmente, concentre-se em questões críticas que se manifestam para seus usuários, para que você não esteja lançando uma série de críticas à pessoa que os leva a descartar tudo o que está dizendo.

A linguagem corporal e o tom são importantes se você estiver falando com eles pessoalmente, seja claro com o que está dizendo e verifique se não está falando baixo com eles ou descartando suas habilidades técnicas. Eles provavelmente estarão na defensiva logo de cara, então você precisa resolver suas preocupações em vez de confirmá-las. Você precisa estar consciente dessa conversa sem ser óbvio demais para que eles subconscientemente pensem que você está do lado deles, e espero que eles aceitem que precisam fazer as alterações que foram trazidas à atenção.

Se isso não funcionar, você pode começar a ficar um pouco mais agressivo. Se o produto puder ser rodado em uma sala de conferências, coloque-o no projetor durante a revisão do código e mostre o bug em primeira mão; é melhor se um gerente estiver ali, para que a pessoa não possa recuar. Isso não é para envergonhá-los, mas forçá-los a aceitar que o problema é real para o usuário e que ele precisa ser corrigido, em vez de apenas uma queixa que você tem com o código.

Eventualmente, se você não está chegando a lugar algum, está cansado de tratar a pessoa como um aluno do jardim de infância, e a gerência desconhece completamente o problema, e isso reflete mal em seu desempenho como revisor de código ou se preocupa com o bem-estar do seu filho. empresa e / ou produto, você precisa começar a conversar com seu chefe sobre o comportamento deles. Seja o mais específico e impessoal possível - faça um caso comercial de que a produtividade e a qualidade estão sofrendo.

As revisões de código podem ser tóxicas, desperdiçar tempo e levar a guerras nerds. Basta olhar para a divergência de opinião sobre coisas como código limpo x comentários, convenções de nomenclatura, testes de unidade e integração, estratégias de check-in, RESTfulness etc., etc.

A única maneira de garantir que você evite isso é anotar as regras para passar na revisão de código.

Então não é uma pessoa que está falhando ou aprovando o check-in. Eles estão apenas verificando se as regras foram seguidas.

E como eles são anotados com antecedência, quando você escreve seu código, pode seguir as regras e não precisa explicar seu raciocínio ou argumentar mais tarde.

Se você não gostar das regras, faça uma reunião para alterá-las.

Não gostaria de agradar seus comentários, porque pode ser considerado condescendente.

Na minha opinião, a melhor prática é sempre se concentrar no código e nunca no autor.

É uma revisão de código , não uma revisão de desenvolvedor , portanto:

• "Este loop while pode nunca terminar", não "Seu loop nunca pode terminar"
• "É necessário um caso de teste para o cenário X", não "Você não escreveu o teste para cobrir este cenário"

Também é muito importante aplicar a mesma regra enquanto fala sobre a revisão com outras pessoas:

• "Anne, o que você acha desse código?", Não "Anne, o que você acha do código de Jon?"

A revisão de código não é a hora para uma revisão de desempenho - deve ser feita separadamente.

Estou surpreso que não tenha sido mencionado em nenhuma resposta até agora, e talvez minha experiência com revisões de código seja incomum, mas:

Por que você está revisando toda a solicitação de mesclagem em uma única mensagem?

Minha experiência com revisões de código é via GitLab; Eu sempre imaginei que outras ferramentas de revisão de código funcionariam da mesma forma.

Quando estou revisando o código, comento linhas específicas e específicas do diff. É extremamente improvável que seja recebido como crítica pessoal, porque é um comentário sobre o código - e é realmente exibido como um comentário sobre o código, mostrado diretamente abaixo do código em que é um comentário.

Eu posso também comentar sobre o pedido na totalidade merge, e muitas vezes fazer. Mas pontos específicos podem ser apontados em linhas específicas do diff. (Além disso, quando um novo commit é adicionado de forma que o diff seja alterado, os comentários no "diff desatualizado" ficam ocultos por padrão.)

Com esse fluxo de trabalho, as revisões de código tornam-se muito mais modulares e menos coesas. Uma linha de uma revisão de código pode simplesmente dizer:

Boa abordagem, envolvendo isso em uma função dedicada!

Ou pode dizer,

Este nome de objeto não corresponde realmente à finalidade do objeto; talvez pudéssemos usar um nome como 'XYZ'?

Ou, se houver grandes problemas com uma seção, devo escrever:

Vejo que esse código funciona (e vejo por que funciona), mas requer um estudo focado para compreendê-lo. Você poderia refatorá-lo em funções separadas para facilitar a manutenção no futuro?

(Exemplo: a função ABC está realmente fazendo três coisas aqui: tocar o foo, barrar o boz e tocar o zorf. Essas podem ser funções separadas.)

Depois de escrever todas as opções acima, posso fazer um comentário resumido sobre toda a solicitação de mesclagem, algo como:

Esse é um ótimo novo recurso e será realmente útil uma vez mesclado. Você pode limpar a nomenclatura das funções e lidar com a refatoração mencionada nos comentários individuais que fiz e depois me avise para analisá-la novamente? :)

Mesmo que a solicitação de mesclagem seja um café da manhã completo para cães, os comentários individuais podem ser simples. Haverá apenas mais deles. O comentário resumido pode dizer:

Sinto muito, mas esse código não é realmente adequado. Existem muitos casos extremos (conforme detalhado nos comentários individuais) que serão tratados incorretamente e fornecerão uma experiência ruim ao usuário ou até corrupção de dados em um caso. (Veja o comentário no commit 438a95fb734.) Mesmo alguns casos de uso normais resultam em desempenho de aplicativo extremamente ruim (detalhes específicos nos comentários individuais no diff para somefile.c).

Para estar pronto para a produção, esse recurso precisará de uma reescrita completa, com mais atenção ao que suposições são seguras em todos os pontos do fluxo. (Dica: nenhuma suposição é segura, a menos que tenha sido verificada.)

Estou encerrando a solicitação de mesclagem com uma reescrita completa.

Resumo: revise os aspectos técnicos do código como comentários em linhas de código individuais. Em seguida, resuma esses comentários em um comentário geral sobre a solicitação de mesclagem. Não seja pessoal - apenas lide com os fatos e, na sua opinião, sobre o código , não sobre o codificador. E baseie sua opinião em fatos, observação precisa e entendimento.

Estou realmente surpreso que ninguém tenha entendido isso, mas há algo errado com a revisão de amostra publicada.

Simplesmente não há motivo para você dirigir-se diretamente a Joe. Que Joe conserte as falhas dele não é da sua conta. Que alguém faz, é da sua conta. Sua preocupação é com a qualidade do código. Portanto, em vez de escrever solicitações / pedidos / demandas (que, se eu fosse Joe, poderia simplesmente recusar porque você não é legítimo para isso), mantenha sua função e escreva uma lista de tarefas anônima simples.

Tentar ser justo em dar pontos bons e ruins não é apenas impossível, mas completamente fora de seu papel.

Aqui está um exemplo de reformulação com o conteúdo retirado de sua revisão:

• Antes de extrair alterações na classe Library \ ACME \ ExtractOrderMail, precisamos corrigir alguns problemas.
• A menos que eu tenha perdido algo, "TempFilesToDelete" não deve ser estático.
• No futuro, podemos chamar a função mais de uma vez por execução, é por isso que precisamos (o que deve ser feito aqui).
• Eu preciso entender por que "GetErrorMailBody" aceita uma exceção como parâmetro. (e eu estou sendo um limite aqui, porque agora você já deve ter uma conclusão )
• SaveAndSend deve ser renomeado para melhor se ajustar ao seu comportamento, como, por exemplo, "SendErrorMail"
• O código comentado deve ser excluído para fins de legibilidade. Usamos o subversion para eventuais reversões.

Se você formular a resenha assim, não importa o quanto o leitor o odeie pessoalmente, tudo o que ele poderá ver aqui são notas sobre melhorias que alguém precisa realizar posteriormente. Quem ? Quando ? Ninguém se importa. O que ? Por quê ? O que você deveria dizer.

Agora, você abordará exatamente o motivo pelo qual as revisões de código estão aumentando a tensão, retirando o fator humano da equação.

O ponto principal da revisão de código é encontrar problemas. Se houver algum erro, a melhor coisa a fazer é escrever um caso de teste que está falhando.

Sua equipe (gerente) deve comunicar que produzir bugs faz parte do jogo, mas encontrá-los e corrigi-los salvará o trabalho de todos .

Pode ser útil ter reuniões regulares (em equipe ou em dupla) e passar por algumas das questões. O programador original não introduziu problemas intencionalmente, e às vezes ele pode pensar que foi bom o suficiente (e às vezes até). Mas ter esse segundo par de olhos dá uma visão completamente nova, e ele pode aprender muito observando os problemas.

É realmente uma coisa cultural e precisa de muita confiança e comunicação. E hora de trabalhar com os resultados.

Eu acho que a coisa mais positiva a fazer seria obter algum consenso sobre os padrões de codificação antes de fazer revisões. Outros tendem a comprar mais quando têm alguma contribuição.

Para algo como convenções de nomenclatura, pergunte a outras pessoas se isso é importante. A maioria dos desenvolvedores concorda especialmente entre seus pares. Quem quer ser a pessoa que não quer concordar com algo tão predominante no mundo da programação? Quando você inicia o processo escolhendo o código de alguém e apontando a falha, ele fica muito na defensiva. Quando os padrões são estabelecidos, haverá discordância quanto à interpretação ou ao que é considerado "bom o suficiente", mas você está melhor do que está agora.

Outra parte desse processo é determinar como as revisões de código lidarão com objeções. Isso não pode se tornar um debate sem fim. Em algum momento, alguém tem que tomar a decisão. Talvez possa haver um terceiro para ser o juiz ou o revisor obtenha todo o poder. O material que precisa ser feito deve ser o objetivo.

A parte final disso é que todos saibam que a Code Reviews não foi sua ideia, eles vão ficar, então todos devem fazer um esforço para fazer o melhor possível. Se todo mundo se sente impotente, talvez eles possam revisar seu código?

Felizmente, algum resultado mensurável para a gerência é limitar bugs, reclamações de clientes, atrasos etc. Caso contrário, alguém acabou de ouvir a palavra-chave "revisão de código" e imaginou que, se apenas a adicionar ao seu processo, milagres ocorrerão sem muito tempo, energia e esforço colocado nisso.

Isso pode ser duro, mas não se preocupe em dar um bom feedback se não houver nada bom para medir.

No entanto, no futuro, à medida que seus desenvolvedores começarem a melhorar seu código, é quando você deseja dar um bom feedback. Você deseja destacar as melhorias no código e também os benefícios para a equipe como um todo. Quando você começa a ver melhorias, elas também acontecem, e as coisas devem começar lentamente a acontecer.

Outra coisa; pode haver um ar defensivo porque eles sentem que não têm voz. Por que não deixá-los revisar o código um do outro? Faça perguntas específicas e tente envolvê-las. Não deveria ser você contra eles; deve ser um esforço de equipe.

1. O que você mudaria nesse código se tivesse tempo?
2. Como você melhoraria essa área da base de código?

Pergunte isso agora e depois daqui a seis meses. Há uma experiência de aprendizado aqui.

O ponto principal - não elogie em termos de código onde não é justificado, mas reconheça o esforço e definitivamente reconheça a melhoria. Tente fazer das revisões um exercício de equipe em vez de um exercício de oposição.

Qualidade sem tensão

Você perguntou como encontrar coisas positivas a dizer sobre o código, mas sua verdadeira pergunta é como evitar tensões na [sua] equipe "enquanto aborda" problemas sérios de qualidade ".

O velho truque de colocar “más notícias em boas notícias” pode sair pela culatra. É provável que os desenvolvedores o vejam pelo que é: um artifício.

Suas organizações de cima para baixo

Seus chefes encarregaram você de garantir a qualidade. Você veio com uma lista de critérios para a qualidade do código. Agora, você deseja que idéias de reforço positivo sejam fornecidas à sua equipe.

Por que nos perguntar o que você precisa fazer para tornar sua equipe feliz? Você já pensou em perguntar à sua equipe?

Parece que você está fazendo o possível para ser legal. O problema não é como você está entregando sua mensagem. O problema é que a comunicação é unidirecional.

Construindo uma cultura de qualidade

É preciso cultivar uma cultura de qualidade para crescer de baixo para cima.

Informe o seu chefe que você está preocupado que a qualidade não está melhorando rápido o suficiente e você deseja tentar aplicar alguns conselhos da The Harvard Business Review .

Encontre-se com sua equipe. Modele os comportamentos que deseja ver em sua equipe: humildade, respeito e compromisso de melhorar.

Diga algo como: “Como você sabe, [o colega de trabalho] e eu fomos encarregados de garantir a qualidade do código, para evitar o tipo de problemas de produção que sofremos recentemente. Pessoalmente, acho que não resolvi esse problema. Acho que meu maior erro não foi envolver todos vocês mais no começo. [colega de trabalho] e eu ainda somos responsáveis perante o gerenciamento pela qualidade do código, mas, daqui para frente, estamos todos juntos no esforço de qualidade. ”

Obtenha idéias da equipe sobre a qualidade do código. (Um quadro branco ajudaria.) Verifique se os requisitos estão lá até o final. Ofereça suas idéias de maneira respeitosa e faça perguntas quando apropriado. Esteja disposto a se surpreender com o que sua equipe considera importante. Seja flexível, sem comprometer as necessidades de negócios.

(Se você tem algum código antigo com o qual se envergonha, pode contorná-lo, incentivando a todos a serem sinceros. No final, deixe as pessoas saberem que você o escreveu. Modele a reação madura que você espera quando outros receberem críticas à construção. )

Revisões do código colaborativo

Eu não trabalhei em um lugar como você descreve, onde alguns programadores seniores revisam todo o código e fazem correções. Não é de admirar que as pessoas reajam como você é um professor, deixando marcas vermelhas em seus papéis.

Se você pode vender a idéia para gerenciar, comece a fazer revisões de código por pares . É melhor fazer isso em pequenos grupos, incluindo você ou outro desenvolvedor responsável. Garanta que todos sejam tratados com respeito.

Um objetivo importante da revisão por pares é garantir que o código possa ser entendido por todos os membros da equipe. Considere o seu exemplo de nomes de funções pouco claros: ouvir de um desenvolvedor mais novo que eles acham o nome da função confuso pode ser mais fácil de aceitar do que outra "correção" do desenvolvedor sênior.

Qualidade é uma jornada

Outra coisa a fazer é eliminar qualquer noção de que uma revisão de código seja um tipo de aprovação / reprovação. Todos devem esperar fazer algumas edições após uma revisão de código. (E seu trabalho é garantir que elas aconteçam.)

Mas se isso não funcionar ...

Vamos supor que você faça alguns progressos para estabelecer uma cultura de qualidade. Você ainda pode não ter todos a bordo. Se alguém ainda não está no programa da qualidade, agora o problema é que eles não se encaixam na equipe, em vez de haver um problema entre vocês dois. Se eles precisarem ser demitidos da equipe, o resto da equipe entenderá melhor os motivos.

Desculpe por mais uma resposta longa, mas acho que os outros não abordaram completamente o elemento humano desta questão.

às vezes até perguntando por que algo foi implementado de uma maneira específica. Quando penso que é ruim, aponto que o teria desenvolvido de outra maneira.

O problema com "Por que você implementou dessa maneira?" é que você coloca o desenvolvedor imediatamente na defensiva. A pergunta em si pode implicar todo tipo de coisa, dependendo do contexto: você é burro demais para pensar em uma solução melhor? Isso é o melhor que pode fazer? Você está tentando arruinar este projeto? Você se preocupa com a qualidade do seu trabalho? etc. Perguntar 'por que' o código foi desenvolvido de uma certa maneira só será conflituoso e isso subverte qualquer intenção pedagógica que seu comentário possa ter.

Da mesma forma, "Eu teria feito isso de maneira diferente ..." também é conflituosa, porque o pensamento imediato que o desenvolvedor terá é " Bem, eu fiz dessa maneira ... Você tem um problema com isso? " precisa ser e afasta a discussão de melhorar o código.

Exemplo:

Em vez de perguntar "Por que você optou por não usar a variável constante para esse valor?", Simplesmente declare "Esse valor codificado deve ser substituído pela constante XYZno arquivo Constants.h". A pergunta que sugere sugere que o desenvolvedor ativamente optou por não usar o constante já definida, mas é perfeitamente possível que eles nem soubessem que ela existia. Com uma base de código grande o suficiente, haverá muitas coisas que cada desenvolvedor não sabe. Essa é simplesmente uma boa oportunidade de aprendizado para o desenvolvedor se familiarizar com as constantes do projeto.

Há uma linha tênue para seguir as revisões de código: você não precisa adornar tudo o que diz, não precisa colocar más notícias com boas notícias e não precisa suavizar o golpe. Pode ser a cultura em que estou, mas meus colegas e eu nunca nos elogiamos nas revisões de código - as partes do código que desenvolvemos que são livres de defeitos são um elogio suficiente. O que você precisa fazer é identificar o defeito que você vê e, talvez, dar uma razão para isso (o porquê é menos útil quando é óbvio / simples).

Boa:

• "O nome dessa variável precisa ser alterado para corresponder ao nosso padrão de codificação."

• "O 'b' neste nome de função precisa ser capitalizado para ser PascalCase."

• "O código desta função não é recuado corretamente."

• "Este código é uma duplicata do código encontrado em ABC::XYZ(), e deve usar essa função."

• "Você deve usar o try-with-resources para garantir que as coisas sejam fechadas corretamente nesta função, mesmo que ocorram erros." [Eu adicionei apenas um link aqui para que usuários não-java soubessem o que significa try-with-resources]

• "Essa função precisa ser reformulada para atender aos nossos padrões de complexidade n-path".

Ruim:

• "Acho que você poderia melhorar esse código alterando o nome da variável para corresponder ao nosso padrão"

• " Talvez seja melhor usar o try-with-resource para fechar corretamente as coisas nessa função"

• "Ele pode ser desejável ter um outro olhar todas as condições esta função. A sua complexidade N-caminho é longo complexidade máxima permitida do nosso padrão."

• "Por que os recuos aqui são 2 espaços em vez dos 4 do nosso padrão?"

• "Por que você escreveu uma função que quebra nosso padrão de complexidade n-path?"

Nas declarações ruins, as partes em itálico são coisas que as pessoas geralmente usam quando querem amenizar o golpe, mas tudo o que realmente faz em uma revisão de código é fazer você parecer inseguro. Se você, revisor, não tem certeza de como melhorar o código, por que alguém deveria ouvi-lo?

As declarações 'boas' são bruscas, mas não acusam o desenvolvedor, não o atacam, não são confrontadoras e não questionam por que o defeito existe. Isso existe; aqui está a correção. Eles certamente não são tão conflituosos quanto a última pergunta "por que".

O problema que você vê é: Os desenvolvedores estão descontentes que seu código seja criticado. Mas esse não é o problema. O problema é que o código deles não é bom (supondo obviamente que suas revisões de código sejam boas).

Se os desenvolvedores não gostam de seu código atraindo críticas, então a solução é fácil: escreva um código melhor. Você diz que teve sérios problemas com a qualidade do código; isso significa que é necessário um código melhor.

"Por que o método deve ter um nome sensato, eu sei o que ele faz?" é algo que eu acho particularmente perturbador. Ele sabe o que faz, ou pelo menos diz, mas eu não. Qualquer método não deve apenas ter um nome sensato, deve ter um nome que deixe imediatamente claro para o leitor do código o que ele faz. Você pode querer ir ao site da Apple e procurar um vídeo da WWDC sobre as mudanças de Swift 2 para Swift 3 - um grande número de alterações feitas apenas para tornar tudo mais legível. Talvez esse tipo de vídeo possa convencer seus desenvolvedores de que desenvolvedores que são muito mais inteligentes do que eles acham nomes de métodos intuitivos muito importantes.

Outro item perturbador foi sua colega que disse "ela mesma me disse que, depois que um relatório de bug foi arquivado por um cliente, ela sabia do bug, mas temia que o desenvolvedor ficasse bravo com ela por apontá-lo". Existe a possibilidade de que haja algum mal-entendido, mas se um desenvolvedor ficar bravo se você apontar um bug para ele, isso é ruim.

Eu respeitosamente discordo do método de revisão de código que você descreveu. Dois funcionários entrando em uma "sala fechada" e saindo com críticas institucionalizam o mesmo tipo de noção contraditória que boas revisões de código devem evitar .

Tornar a revisão do código uma experiência positiva na medida do possível é essencial para torná-lo bem-sucedido. O primeiro passo é remover a noção contraditória de revisão. Torne-o um evento de grupo semanal ou quinzenal ; garanta que todos saibam que podem participar. Encomende pizza ou sanduíches ou qualquer outra coisa. Nem chame isso de 'revisão de código' se isso provocar conotações negativas. Encontre algo para comemorar, incentivar e compartilhar - mesmo que não seja nada além de progresso no sprint ou na iteração atual. Revezam-se atribuindo liderança sobre a revisão.

Faça do processo um esforço para servir o produto e as pessoas. Se eles são feitos de maneira construtiva e positiva, em que boas técnicas ou padrões são compartilhados e incentivados, assim como os pobres são desencorajados - todos se beneficiam. Todo mundo é treinado em público. Se você tem um programador problemático que não está "entendendo", ele deve ser abordado de forma privada e separada - nunca na frente do grupo mais amplo. Isso é separado da revisão de código.

Se você está tendo problemas para encontrar algo "bom" para mencionar, isso para mim levanta uma pergunta: se o progresso está sendo feito no projeto e as pessoas estão trabalhando, esse progresso por si só é algo para comemorar. Se você realmente não encontra nada de bom, isso implica que tudo o que foi feito desde a última revisão é ruim ou não é melhor que neutro . Esse é realmente o caso?

Quanto aos detalhes, padrões comuns são essenciais. Dê a todos uma participação no que está sendo feito. E permita que novas e melhores técnicas sejam integradas à sua base de código. O fracasso em fazer isso garante velhos hábitos nunca é eliminado sob o pretexto de "sempre fizemos dessa maneira".

O ponto disso tudo é que as revisões de código são um pouco ruins porque são mal implementadas, usadas como martelos para menosprezar programadores menos experientes ou menos qualificados, e isso não serve a ninguém. Os gerentes que os usam dessa maneira provavelmente também não serão gerentes muito eficazes. Boas revisões de código em que todos são participantes servem a todos - o produto, os funcionários e a empresa.

Desculpas pelo tamanho da postagem, mas tendo participado de um grupo em que a revisão de código foi amplamente ignorada, isso levou a um legado de código impossível de manter e a apenas uma faixa restrita de desenvolvedores capazes, mesmo que autorizados a fazer alterações em uma base de código de um ano. Era um caminho que eu optaria por não percorrer novamente.

O paradoxo do bom código é que ele não se destaca e parece muito direto e fácil de escrever. Eu realmente gosto do exemplo do jogador de sinuca desta resposta . Nas revisões de código, isso facilita muito o encobrimento, a menos que seja um refator de código incorreto.

Faço questão de procurá-lo. Se eu estou revisando o código e analisando um arquivo que foi tão fácil de ler que parece enganosamente fácil de escrever, basta digitar rapidamente "Eu gosto de como os métodos aqui são curtos e limpos" ou o que for apropriado .

Além disso, você deve dar o exemplo. Você deve insistir para que seu código seja revisado também e deve modelar como deseja que sua equipe se comporte ao receber correção. Mais importante, você deve sinceramente agradecer às pessoas pelo feedback. Isso faz mais diferença do que qualquer feedback unilateral que você possa dar.

Parece que o verdadeiro problema é que são apenas duas pessoas que fazem todas as revisões de código, das quais somente você as leva a sério, o que acabou em uma situação infeliz, com muita responsabilidade e muita responsabilidade. pressão dos outros membros da equipe.

Uma maneira melhor seria distribuir a responsabilidade de fazer as revisões de código pela equipe e fazer com que todos participem, por exemplo, permitindo que os desenvolvedores escolham quem revisará seu código. Isso é algo que sua ferramenta de revisão de código deve oferecer suporte.

Vi isso acontecer em primeira mão e quero alertá-lo para longe das respostas desafiadas pela inteligência emocional - elas podem matar equipes inteiras. A menos que você queira recrutar, treinar e normalizar novos desenvolvedores a cada ano, é essencial criar um relacionamento positivo com seus colegas. Afinal, não é o objetivo de fazer essas revisões melhorar a qualidade do código e promover uma cultura em que a qualidade do código seja mais alta? Eu argumentaria que é realmente parte do seu trabalho fornecer um reforço positivo como meio de integrar esse sistema de revisão de código à cultura da equipe.

De qualquer forma, parece que você precisa revisar seu sistema de revisão de código. No momento, pelo que parece, tudo no seu processo de revisão é ou pode ser interpretado como subjetivo e não objetivo. É fácil ter sentimentos feridos quando parece que alguém está apenas separando seu código porque não gosta, em vez de ter um motivo que pode citar quando algo não se encaixa nas diretrizes. Dessa forma, é fácil rastrear e 'celebrar' melhorias positivas na qualidade do código (com relação ao seu sistema de revisão) da maneira que for apropriada para a cultura do seu escritório.

Os Líderes Técnicos precisam se reunir fora de uma sessão de revisão e elaborar uma Diretriz de Codificação / Lista de Verificação de Revisão de Código e precisam ser respeitados e referidos durante a revisão. Este deve ser um documento ativo que pode ser atualizado e refinado à medida que o processo se desenvolve. Essas reuniões do líder técnico também devem ocorrer quando a discussão "Como sempre fazemos as coisas" versus "Novas e aprimoradas maneiras de fazer as coisas" deve ocorrer, sem que o desenvolvedor seja revisado sentindo que a discordância é resultado de seu código. Uma vez que a diretriz inicial foi mais ou menos suavizada, outra maneira de reforçar positivamente os desenvolvedores é pedir feedback e, em seguida, realmente agir. e evoluir o processo como uma equipe, isso faz com que eles sejam atualizados para começar a revisar o código das placas, para que você não fique preso nas revisões até se aposentar também.

Instalações ...

Programadores são solucionadores de problemas. Estamos condicionados a iniciar a depuração quando apresentar um problema ou erro.

Código é um meio de formato de estrutura de tópicos. Mudar para uma narrativa no formato de parágrafo para obter feedback introduz uma desconexão que deve ser traduzida. Inevitavelmente, algo se perde ou é mal compreendido. Inevitavelmente, o revisor não está falando no idioma do programador.

As mensagens de erro geradas por computador raramente são questionadas e nunca são consideradas uma afronta pessoal.

Os itens de revisão de código são mensagens de erro geradas por humanos. Eles têm como objetivo captar os casos extremos que os programadores e as ferramentas automatizadas ignoram, bem como os efeitos colaterais inevitáveis ​​em outros programas e dados.

Conclusões ...

Assim, quanto mais itens de revisão de código puderem ser incorporados às ferramentas automatizadas, melhor serão recebidos.

A ressalva é que, para permanecer inquestionável, essas ferramentas devem ser atualizadas continuamente, geralmente diariamente ou semanalmente, para estar em conformidade com todas as alterações de procedimentos, padrões e práticas. Quando um gerente ou equipe de desenvolvedores decide fazer uma alteração, as ferramentas devem ser alteradas para impor isso. Grande parte do trabalho do revisor de código passa a ser a manutenção das regras nas ferramentas.

Exemplo de revisão de código ...

Uma reescrita do exemplo dado incorporando estas técnicas:

• Sujeito:

  • Classe Library \ ACME \ ExtractOrderMail.

• Questão de princípio ...

  • TempFilesToDelete é estático
    • As chamadas subseqüentes ao GetMails lançam uma exceção, pois os arquivos são adicionados, mas nunca são removidos após a exclusão. Embora apenas uma ligação seja feita agora, o desempenho poderá ser melhorado no futuro com algum paralelismo.
    • TempFilesToDelete como uma variável de instância permitiria que vários objetos fossem usados ​​em paralelo.
• Questões secundárias ...
  • GetErrorMailBody possui um parâmetro de exceção
    • Como ele não lança uma exceção em si e apenas passa isso para o ToString, é necessário?
  • Nome SaveAndSend
    • O email pode ou não ser usado para relatar isso no futuro e esse código contém a lógica geral para armazenar uma cópia persistente e relatar erros. Um nome mais genérico permitiria tais alterações antecipadas sem alterar os métodos dependentes. Uma possibilidade é StoreAndReport.
  • Comentando código antigo
    • Deixar uma linha comentada e marcada como OBSOLETE pode ser muito útil na depuração, mas uma "parede de comentários" também pode ocultar erros no código adjacente. Ainda o temos no Subversion. Talvez apenas um comentário referencie exatamente onde no Subversion?

Se você não tem nada de bom a dizer sobre o código existente (o que parece compreensível), tente envolver o desenvolvedor na melhoria.

Em um patch para uma alteração funcional ou correção de bug, não é útil ter outras alterações (renomear, refatorar, o que for), agrupadas no mesmo patch. Deve fazer a alteração que corrige o erro ou adiciona o recurso, nada mais.

Onde a renomeação, refatoração e outras alterações forem indicadas, faça-as em um patch separado, antes ou depois.

• Isso é muito feio, mas acho que é consistente com todos os outros códigos desagradáveis. Vamos limpar isso mais tarde (em um patch com, idealmente, nenhuma alteração funcional).

  Também ajuda se você ingressar na refatoração e permitir que eles revisem seu código. Isso lhe dá a chance de dizer por que você acha que algo é bom, e não ruim, e também para mostrar um exemplo de como aceitar críticas construtivas.

Se você precisar adicionar testes de unidade a um novo recurso, tudo bem, eles serão apresentados no patch principal. Mas se você estiver corrigindo um bug, os testes deverão ser executados em um patch anterior e não passar para que você possa demonstrar que a correção realmente corrigiu o bug.

Idealmente, o plano (sobre como você pode testar uma correção, ou o que refatorar e quando) deve ser discutido antes do término do trabalho, para que eles não tenham se esforçado muito em algo antes de descobrir que há um problema com ele.

Se você achar que o código não lida com as entradas que acha que deveria, também pode ser uma incompatibilidade no que o desenvolvedor vê como uma entrada razoável. Concorde com antecedência também, se possível. Pelo menos, tenha alguma discussão sobre o que ele deve ser capaz de lidar e com que maldade pode ser permitido.

Eu acho que é um erro supor que exista uma solução técnica ou fácil para: "meus colegas de trabalho ficam chateados quando eu julgo o trabalho deles pelos meus padrões e tenho algum poder para aplicá-lo".

Lembre-se de que as revisões de código não são apenas uma discussão do que é bom ou ruim. Eles são implicitamente um "quem está no quintal que estamos usando", um "quem toma a decisão" e, portanto, mais insidiosamente - uma classificação.

Se você não abordar esses pontos, será difícil fazer revisões de código de uma maneira que não tenha os problemas que encontrar. Há alguns bons conselhos aqui sobre como fazê-lo, mas você definiu uma tarefa difícil.

Se você estiver certo, sem espaço de manobra, apontá-lo é um ataque: alguém estragou tudo. Caso contrário: seu outro MBA que não consegue. De qualquer maneira, você será o cara mau.

No entanto, se o que a revisão está procurando e por que é claro e acordado, você tem uma chance decente de não ser o vilão. Você não é o guardião, apenas um revisor. Conseguir este acordo é um problema difícil de resolver [1]. Gostaria de lhe dar um conselho, mas ainda não entendi o jeito ...

[1] Não foi resolvido apenas porque as pessoas disseram "ok" ou pararam de brigar por causa disso. Ninguém quer ser o cara que diz que X simplesmente não é prático para nossa {inteligência, experiência, mão-de-obra, prazos, etc}, mas isso não significa que, na verdade, se trata de algum exemplo específico de fazer X ...

As revisões de código devem ser mútuas. Todo mundo criticou todo mundo. Deixe o lema ser "Não fique bravo, fique quieto". Todo mundo comete erros e quando as pessoas disserem como corrigir seu código, entenderão que esse é apenas o procedimento normal e não um ataque a eles.

Ver o código de outras pessoas é educativo. Compreender o código até o ponto em que você pode apontar seu ponto fraco e ter que explicar que esse ponto fraco pode lhe ensinar muito!

Há pouco espaço para elogios em uma revisão de código, pois o ponto principal é encontrar falhas. No entanto, você pode elogiar as correções . Tanto a atualidade quanto a limpeza podem ser elogiadas.