As revisões de código geralmente causam polêmica. Ao preparar a palestra “Desaprendemos do comportamento tóxico na revisão de código” na conferência AlterConf, eu estava pronto para ouvir várias objeções e críticas. Mas ela não esperava que a comunidade apoiasse tanto a ideia. Eu assumi resistência, mas a comunidade me recebeu muito bem e me aprovou.

Me pediram para compartilhar os slides , mas agora eu pensava que os slides em si eram de pouca utilidade e foram tirados de contexto: eles não têm explicações. Por isso, decidi publicar este artigo. Mais tarde, os organizadores da conferência enviaram um vídeo .

Listados abaixo estão alguns tipos de comportamentos improdutivos de revisão de código e recomendações sobre como tornar o processo mais amigável e eliminar a toxicidade. Todos os modelos comportamentais foram testados por mim ou em uma empresa conhecida por mim. No passado, esses pecados também foram trazidos para mim.

Comportamento improdutivo nº 1: comunicando a opinião como um fato

Não faça declarações se não puder consultar a documentação, recomendações formalizadas e exemplos de código para apoiar essas declarações. As pessoas devem saber por que estão sendo solicitadas a fazer alterações, e as preferências pessoais de outro desenvolvedor não são um argumento suficientemente bom.

Em vez de dizer:

Este componente deve ser tornado sem estado.

... é melhor fornecer algum contexto:

Como esse componente não possui ciclo de vida ou métodos de estado, ele pode ser tornado sem estado. Isso melhorará o desempenho e a legibilidade do código. * Aqui * alguma documentação.

A transferência de opinião como um fato é freqüentemente encontrada em discussões de estilo e sintaxe. Esses são tópicos realmente importantes, mas não para revisões de código, porque o estilo e a sintaxe não têm nada a ver com o problema que o desenvolvedor resolve inicialmente.

É melhor conduzir essas discussões separadamente e determinar o estilo para toda a equipe. Implemente linter e correções automáticas de código . Você consultará essas recomendações de estilo, não sua opinião pessoal.

É especialmente importante não dar sua opinião como um fato se você tiver uma classificação e autoridade mais altas em uma equipe ou empresa. O desenvolvedor tem a impressão de que ele não tem escolha a não ser obedecer obedientemente aos seus requisitos.

Comportamento improdutivo # 2: avalanche de comentários

Quando uma pessoa comete um erro, há uma boa chance de que esse erro ocorra em vários lugares. Notei que os revisores às vezes indicam cada um dos casos, em vez de deixar uma nota detalhada com links para recursos úteis.

A consolidação dos comentários permite enviar a mesma mensagem sem suprimir o autor. Uma avalanche de comentários duplicados sobre uma questão parece uma questão .

Improdutivo e esmagador:



Vários comentários para um erro recorrente (espaços no final da linha)

Uma opção mais útil:


Feedback consolidado

Entendo que, às vezes, é útil apontar para todos os lugares do erro, pois o comentário desaparece quando corrigido nas confirmações subsequentes. Mas se o erro ocorrer muitas vezes, é óbvio que o desenvolvedor não estava ciente de um guia específico e ele deveria apenas apontar os recursos corretos.

Comportamento improdutivo número 3: peça aos engenheiros para resolverem os problemas de outras pessoas "enquanto estiverem aqui"

Não peça aos desenvolvedores que lidem com problemas que não estão diretamente relacionados ao conjunto de alterações ou ao problema que este código está tentando resolver. Mesmo que um desenvolvedor expanda ou modifique o código incorreto com muitas práticas ruins, não peça para ele limpar e corrigir esse código estranho.

Não proponho privar os desenvolvedores da responsabilidade pelo código apenas porque eles não o escreveram inicialmente. De fato, não é bom dizer algo como "O código de outra pessoa não é problema meu". É apenas mais apropriado criar um ticket separado e solicitar solicitação para corrigir código incorreto. Assim, você evita um aumento acentuado no volume do trabalho de alguém, resolvendo o problema com dívidas técnicas.

TL; DR : Não peça ao desenvolvedor que corrija os problemas "enquanto estiverem aqui". Se o código fizer o que é necessário no ticket e não introduzir novos problemas na base de códigos, aprove-o e crie um ticket para limpar a base de códigos.

Comportamento improdutivo nº 4: faça perguntas condenadoras

Evite fazer perguntas condenatórias como esta:

Por que você não fez ____ aqui?

Isso implica que alguma solução simples deve ser óbvia. Isso força o desenvolvedor a se defender.

Muitas vezes, essas questões condenatórias são simplesmente demandas veladas. Em vez disso, ofereça uma recomendação (com documentação e links), omitindo palavras duras.

Você pode fazer ____, que tem a vantagem de ____.

Comportamento improdutivo n ° 5: sarcasmo

Não há lugar para sarcasmo nas críticas. Como regra, comentários sarcásticos não fornecem contexto e feedback eficaz. Em vez disso, descreva o problema em detalhes e forneça recomendações, mas deixe de lado as piadas cáusticas.

Improdutivo:

Você já testou esse código antes de enviar?

Útil

Falha ao inserir um número negativo. Você poderia fazer isso?

Aqui está outro comentário de exemplo em uma revisão de código que não é engraçado nem útil:

Nós não somos maus, somos impiedosos. Como você pode ver, eu escrevi "bip!" - Ao importar todos os arquivos em que você toca. Eu tinha em mente o seguinte: “Sua importação viola nossa convenção padrão, que pressupõe uma certa ordem: primeiro, módulos internos, depois terceiros e depois o nível do projeto”, mas essa frase é muito longa para ser digitada em cada caso.

No exemplo acima, "bipe!" - completamente inútil e sem sentido. Este é um humor pedante que não ajuda o autor.

Comportamento improdutivo # 6: Emoji em vez de descrever o problema

Ao apontar problemas no código, evite emoticons com o polegar para baixo ou emoji com um homenzinho doentio. É tão inútil quanto o sarcasmo, pelas mesmas razões. Os emoji são misteriosos, fáceis de interpretar mal. As pessoas estão perdendo tempo tentando entender seus pensamentos.


Não use emojis para indicar problemas de codificação

De qualquer forma, você não deve ter uma reação emocional aos erros de programação.

É bastante normal usar emoticons positivos, como "polegar para cima" ou "aplausos!", Mas não para indicar problemas, mas como uma resposta a um bom código.


Emoticons de aprovação são ótimos

Comportamento improdutivo nº 7: não responda a todos os comentários

Os autores também contribuem para a toxicidade da discussão. Se você combinar o código sem responder a todos os comentários, isso é surpreendente para a pessoa: ele tentou ajudá-lo e você deixou claro que algumas revisões não importam.

Se o comentário for irrelevante ou você não tomará uma ação, apenas explique brevemente o motivo.

Não ignore colegas.


Combinando código sem responder a um comentário

Comportamento improdutivo # 8: Ignorando o comportamento tóxico se vier dos principais profissionais

O comportamento tóxico não deve ser ignorado ou subestimado apenas porque o desenvolvedor é um excelente profissional e um funcionário extremamente produtivo. Embora ele faça um trabalho fantástico, é importante ter em mente que seu comportamento tóxico leva ao estresse e à exaustão de outros desenvolvedores.

Experiência com uma pessoa que exibe comportamento tóxico:

Outros descobrirão que trabalhar com essa pessoa esgota e desmotiva. Eles farão qualquer coisa para evitar interagir com ele, mesmo que isso afete negativamente sua capacidade de executar tarefas. As comunicações em toda a organização serão interrompidas e os funcionários começarão a procurar empregos em outros lugares. Enquanto você enfrenta as consequências de uma fuga de talentos e de projetos malsucedidos, esse desenvolvedor em particular continuará a trabalhar com calma como se nada tivesse acontecido. - Joseph Gefro

Se não forem tomadas medidas para corrigir a situação, são possíveis sérias conseqüências: os desenvolvedores serão sobrecarregados, atacados e desmotivados. Eles começarão a temer o feedback, o que de fato deve ajudá-los a crescer.

Pessoalmente, me senti muito preocupado sempre que recebi um e-mail com comentários sobre minha solicitação de recebimento de um ex-colega (conhecido por suas críticas tóxicas e inúteis). Embora o comportamento tóxico afete a todos de maneira diferente, mas definitivamente ninguém se beneficia dessa toxicidade.

Nota : Quero deixar claro que, se o desenvolvedor não resistir e, uma vez demonstrado tal comportamento, isso não o tornará "tóxico". Estamos falando de repetidos insultos e comentários cáusticos.

Práticas úteis de revisão de código

Abaixo estão algumas recomendações que se aplicam a qualquer comunicação normal, embora aqui falemos no contexto da programação e das revisões de código.

Comportamento útil nº 1: use perguntas ou recomendações para criar diálogo

Nunca peça às pessoas que façam correções ou façam perguntas de reprovação, porque isso interfere no diálogo entre você e a outra pessoa.

Por que você não combinou essas conversões em um arquivo com constantes?

Formalmente, isso é uma pergunta, mas não cria um diálogo entre você e o interlocutor. Ele apenas o faz se defender. Em vez disso, pergunte o que a outra pessoa pensa da sua decisão, por exemplo:

O que você acha de colocar essas conversões em um arquivo constante? Existem muitos deles, portanto, um arquivo separado pode muito bem fazer sentido no momento.

... ou faça uma recomendação:

Neste arquivo, você tem muitas chamadas de tradução para a "função x". Pode fazer sentido criar um arquivo separado com suas constantes.

Comportamento útil # 2: colabore, não esconda

Quando você programa em conjunto, precisa estar por perto, fazer perguntas, discutir e apontar para recursos.

“... Quando você quer ajudar ou trabalhar em conjunto, deve estar totalmente envolvido, não apenas intervir às vezes” - Guia do Centro de Recursos

Comportamento útil nº 3: responda a cada comentário

Se você, como autor, não planeja aplicar o conselho de um revisor, faça uma anotação relatando-o. Não ignore aqueles que dedicam tempo para ajudá-lo.

Por exemplo:

Pessoa A: - O que você acha de criar uma função auxiliar para esta chamada de API? Caso contrário, está tudo bem.

Pessoa B: - Esta linha não fazia parte do meu changeset. Vou combinar o código, criar um ticket separado no GitHub e escrevê-lo no plano de trabalho do nosso grupo.

Comportamento útil # 4: Saber quando organizar uma reunião cara a cara

Após dezenas de comentários e soluções propostas, deve ficar claro que a comunicação on-line se tornou improdutiva para o problema em questão. Envie um convite para reunião a todos os seus colegas envolvidos.

Assim, o grupo poderá tomar uma decisão rapidamente e aplicá-la.

Problemas que levam horas e muitos comentários geralmente podem ser resolvidos em alguns minutos de conversa produtiva. - "Java puro"

Comportamento útil nº 5: use oportunidades de aprendizado e não apareça

Antes de participar de uma revisão de código, pergunte-se:

Seu comentário realmente ajuda você a aprender ou está encontrando falhas?

Pense no seu comentário. Lembre-se de que o objetivo de uma revisão de código é ensinar e ajudar outros desenvolvedores a crescer. Esta não é uma plataforma para performances.

Comportamento útil # 6: não demonstre surpresa

Cuidado para não demonstrar surpresa se uma pessoa não souber de algo. Não chateie as pessoas por elas já saberem essas informações. Por outro lado, sinta-se à vontade para admitir que você não tem experiência no tópico - essa é uma ótima maneira de pedir ajuda.

Consulte a regra "Não finja surpresa" no tutorial da Central de recursos para obter mais informações.

Comportamento útil nº 7: automatize tudo o que puder

Não faz sentido discutir bugs que podem ser detectados por linters, ganchos Git ou testes automatizados. Esta é uma tonelada de comentários extras que parecem nitpicking. As pessoas não são muito boas em identificar esses erros e, portanto, ferramentas de automação foram criadas.

Também existem ferramentas para executar testes automaticamente ao adicionar novo código. Eles exibem avisos se um conjunto de alterações violar um dos testes. Por exemplo, TeamCity e Jenkins CI.

Além disso, use os ganchos Git para executar testes e linters no novo código. Eles interceptarão o commit se encontrarem erros.

Deixe a ferramenta indicar problemas, para que as pessoas não precisem.

Comportamento útil nº 8: não ultrapasse o comportamento tóxico

Não há necessidade de adotar comportamento tóxico em sua revisão de código, porque parece vingança ou algum ritual de trote para novos desenvolvedores.

Encontre colegas que o apoiarão.

Se você observar revisões improdutivas de códigos, tente informar um colega, fale direta e honestamente (se você se sentir seguro em sua posição / empresa).

Comportamento útil n.º 9: Os gerentes, consideram cuidadosamente os candidatos, ouvem a equipe e usam sua autoridade

Os gerentes têm grandes oportunidades para criar uma atmosfera positiva e favorável na equipe.

Nós reformulamos as dicas do artigo "Nocivo para desenvolvedores tóxicos" :

• Impedir que desenvolvedores tóxicos apareçam na equipe. Ao contratar, preste atenção não apenas ao treinamento técnico. Descubra como o candidato colabora e se comunica. Analise criticamente seu trabalho e veja como ele reage. Certifique-se de que cada candidato melhore a cultura da empresa e não apenas se encaixe nela.
  
• Quando um desenvolvedor tóxico ainda entrar no estado ou herdar, peça a cada funcionário uma opinião sobre isso em uma conversa pessoal. Se o desenvolvedor for tóxico, ele aparecerá em análises sobre ele.
  
• Converse com um desenvolvedor tóxico. Dê exemplos específicos de comentários efetivos em uma revisão de código. Trabalhe continuamente com ele, continuando a coletar informações em conversas pessoais com seus colegas e gerente.
  
• Não isole o revelador tóxico. (*)
  
• Repita para os funcionários sobre a necessidade de um ambiente amigável.

(*) Embora o artigo proponha isolar desenvolvedores tóxicos, considero importante incentivar o desenvolvedor tóxico a trabalhar com a equipe, mas de maneiras mais saudáveis. O isolamento não resolverá o problema. Se você fizer um trabalho separado, a toxicidade diminuirá no curto prazo, mas o desenvolvedor não desistirá de seu comportamento improdutivo. Ele só perderá o pódio para demonstrá-lo.

Comportamento útil nº 10: defina o padrão enquanto a equipe é pequena e em crescimento

Pequenas equipes são capazes de aceitar novas idéias e implementá-las. Mesmo que você não considere necessário definir padrões, porque agora não há problemas, mas é importante manter boas práticas de cooperação quando o reabastecimento chegar.

Comportamento útil nº 11: entenda que você pode fazer parte do problema

Para criar um ambiente mais favorável, é importante ser honesto consigo mesmo e refletir sobre qualquer comportamento ineficaz.

Quando júnior, notei um erro no código de alguém várias vezes e fiquei feliz, porque eu poderia deixar um comentário! Agora entendo que aproveitei esta oportunidade para me gabar e não ajudar. Você precisa avaliar cuidadosamente suas ações.

Penso que é útil que todos dediquem um tempo a essa introspecção difícil.

E o ultimo ...

Não estamos falando sobre o conteúdo das resenhas, mas apenas sobre o tom

Eu sei que as críticas são importantes e não estamos lutando contra elas. Não peço que você comprometa a qualidade do código. A cultura benevolente da revisão de código e a alta qualidade do código não devem ser mutuamente exclusivas.

Eu só espero que as pessoas tomem medidas para fornecer feedback construtivo e eficaz e criar condições mais favoráveis ​​para que os desenvolvedores se sintam confortáveis, aprendam, cresçam e não tenham medo de cometer erros. Todos nós podemos melhorar juntos.