Eu constantemente comprometo-me com projetos de código aberto (Red Hat, etc.). E ele percebeu que as análises negativas de código, subjetivas em essência, levam mais tempo. Na maioria das vezes isso acontece com confirmações, nas quais o mantenedor, por algum motivo, não gosta da sua alteração. Na melhor das hipóteses, essa estratégia de revisão de código resulta em perda de tempo em debates sem sentido; na pior das hipóteses, desencoraja ativamente o comprometimento, criando um ambiente hostil e elitista.

A revisão do código deve ser objetiva, concisa e, se possível, conter apenas alguns fatos. Este não é um debate político ou emocional, mas técnico. Seu objetivo é avançar, desenvolver o projeto e todos os participantes. Qualquer confirmação deve ser avaliada apenas pelos méritos e não por uma opinião subjetiva.

Estratégias de revisão de código

Aqui estão algumas estratégias a serem lembradas ao considerar o código que você (como mantenedor) por algum motivo não gosta:

1. Reformule a objeção como uma pergunta

• Ruim: "Essa mudança tornará XXX impossível" (isso é um exagero; é realmente impossível?)
  
• Bom: "Como vamos fazer o XXX depois da sua alteração?"

2. Evite exageros

Simplesmente expresse suas preocupações e faça perguntas para ajudar a alcançar o resultado desejado.

• Ruim: "Essa mudança destruirá a produtividade".
  
• Bom: “Parece que X pode ser mais lento que o Y existente; "você fez medições / coletou dados para mostrar que não é assim?"
  
• Melhor (se você tiver tempo): “Por enquanto, estou coletando dados. Tentarei verificar se X não é mais lento que Y. "
  
• Também é bom: “Essa alteração altera um único ciclo O (n) para um ciclo O (n²) duplo-aninhado; isso afetará o desempenho? "

3. Deixe comentários maliciosos para si mesmo

É melhor manter alguns pensamentos com você. Se você não pode dizer educadamente, é melhor ficar calado.

• Ruim: "Eu acho que essa é uma mudança ruim que vai estragar tudo."
  
• Ruim: "Você tem certeza de que o desenvolvimento de software é a opção de carreira certa para você?"

4. Aja positivamente

Talvez você tenha uma idéia diferente de como resolver o problema? Se você agir positivamente, encontrará uma solução melhor do que qualquer uma das opções originais.

• Ruim: "Essa mudança é péssima, minha versão é melhor."
  
• Bom: "Eu também tenho uma mudança neste lugar: talvez possamos comparar e / ou combinar idéias".
  
• Também é bom. "Eu tenho uma mudança semelhante no meu trabalho, mas decidi fazer o X, porque ZZZ; por que você escolheu Y? "

5. Lembre-se de que todo mundo tem uma experiência diferente.

Em todos os outros aspectos, um engenheiro absolutamente competente pode não conhecer há alguns anos alguns fatos que você considera como bom senso. Não há nada de errado em dizer a coisa óbvia, a menos que você patrocine ou com intuito malicioso.

• Ruim: "Você não vê que isso está claramente errado?"
  
• Bom: "Isso não é verdade porque gera uma exceção de ponteiro nulo quando X é Y."

6. Não subestime a complexidade do que não é óbvio

Lembre-se de que as coisas que são óbvias para você podem não ser óbvias para todos. Ao sugerir abordagens alternativas e apontar exemplos úteis, você pode ajudar todos a sincronizar.

• Ruim: "Por que não esmagar a gnose?"
  
• Bom: "Se você esmagar a gnose, essa parte poderá se tornar mais fácil (veja XXX como exemplo)."

7. Respeito

Às vezes, um commit simplesmente não atende ao padrão mínimo de qualidade. É normal dizer isso, mas mostrar respeito não requer esforço adicional.

• Ruim: "Este é um código estúpido escrito por uma pessoa estúpida."
  
• Bom: “Obrigado pela sua contribuição. No entanto, não pode ser adotado como está; existem muitos problemas (como indicado acima). ”
  
• Também é bom: “Como afirmado acima, há vários problemas com esse commit. Talvez dê um passo atrás e fale sobre cenários de uso? Isso ajudará a encontrar o caminho ".

8. Gerencie suas expectativas (e seu tempo)

Se o commit for muito grande e não puder ser considerado rapidamente, é normal dizer isso imediatamente. Então procure uma solução.

• Ruim: "Eu não aceito, é muito grande."
  
• Também é ruim: ignore o commit até que ele desapareça.
  
• Bom: “Você poderia dividi-lo em confirmações menores? Não tenho muito tempo para uma revisão de código, mas é uma confirmação muito grande / complicada para uma revisão. "

9. Diga "por favor" (mostre cortesia)

Apenas dizendo "por favor", você mostra que respeita a hora do remetente, especialmente quando deseja alterar a formatação ou o estilo, o que pode parecer uma pequena alteração. Exemplos:

• "Você poderia documentar as alterações nas lacunas em outra solicitação de pool?"
  
• "Você poderia alinhar essas definições de variáveis ​​para facilitar a leitura?"

10. Inicie uma conversa

Se, depois de tudo isso, você ainda não gosta de algo, mas não sabe ao certo por que, talvez seja necessário aturar isso. Ou diga: "Não gosto, mas não sei por que, podemos conversar sobre isso?" Essa é uma pergunta razoável, e mesmo que demore um pouco, geralmente vale a pena, porque agora você tem duas pessoas e ambas estão aprendendo (explicando e ouvindo), e não duas que se opõem.

Mesmo engenheiros qualificados e experientes devem ser capazes de dizer: "Não entendo por que não gosto". Este não é um convite para atacar a posição do revisor, mas uma busca honesta por conhecimento.

Sumário

Evite declarações hiperbólicas ou pomposas, evite disputas, expressões elitistas ou degradantes e construções como "óbvio" e "por que você simplesmente não ...". Use declarações claras e factuais e linguagem de apoio, faça perguntas e siga em frente. Lembre-se de que colegas e colaboradores também são pessoas. O tempo deles merece o mesmo respeito que o seu.