Talvez você tenha lido a primeira parte do artigo sobre o código de revisão pelo revisor (a propósito, já conseguimos discuti-lo na última edição do podcast Zinc Prod ).
Como o artigo ganhou muitos gostos, eu escrevi a continuação prometida sobre a revisão de código, por outro lado - do autor das alterações de código
Como sempre, diremos MR (solicitação de mesclagem) em vez de CL, porque poucas pessoas entendem o termo CL.
As instruções originais para os autores do MR, de acordo com o Google, podem ser encontradas aqui , e darei um breve aperto.
Então vamos
Descrição do MR
No Google, a descrição das alterações é armazenada no histórico do sistema de controle de versão e é muito provável que muitas pessoas o leiam no futuro. Portanto, a descrição do MR é muito importante.
A primeira linha (no título) deve conter uma frase descrevendo o que foi feito no MR. Além disso, de acordo com a tradição, é usado um estilo imperativo (imperativo), isto é, Excluir blablabla , não Excluindo blablabla
A descrição em si deve ser informativa, conter uma breve descrição do problema que está sendo resolvido, links para os documentos necessários (se necessário), tarefas do rastreador de tarefas e outro contexto. Mesmo no pequeno MR, algo assim deveria ser.
Uma descrição do tipo "Corrigir bug", é claro, é considerada inadequada.
RM deve ser o menor possível
- Pouco MR pode ser verificado rapidamente
- A verificação será mais significativa
- Menos probabilidade de perder um bug.
- Não é tão ofensivo se todo o MR for rejeitado. É muito ruim quando muito trabalho é feito, e acontece que tudo isso não era necessário
- Mais fácil de promover mudanças, menos conflitos
- É mais fácil obter código de boa qualidade.
- Quanto mais alterações por vez, mais difícil é reverter o código, se necessário
Muito raramente, há uma situação em que é impossível reduzir o tamanho da RM, dividindo-a em pedaços. O revisor tem o direito de rejeitar a RM se for muito grande
Obviamente, não pode haver regra rígida e rápida, qual MR será considerado grande, qual pequeno. 100 linhas de código são grandes ou não? Quem sabe
- MR deve fazer uma coisa. Normalmente, esse não é o recurso completo, mas parte dele
- Refatoração separada em um MR separado
RM deve ser pequena, mas auto-suficiente
- Tudo o que um revisor precisa entender MR deve estar nesse MR
- Após injetar o código, o sistema deve funcionar normalmente.
- Se um método API for adicionado, os métodos para usá-lo deverão ser demonstrados no mesmo MR. Em outras palavras, a RM não deve ser tão pequena que seria difícil entender como ela será usada, quais consequências ela levará.
- Cubra o código com testes e os testes devem estar no mesmo MR
Não leve a sério
Às vezes, os revisores não são muito educados, eles podem escrever algo ruim sobre o seu código. Isso não é muito profissional da parte deles, mas muitas vezes ainda existe um certo grau de verdade em tais comentários, e isso deve ser levado em consideração. Não responda muito severamente. Isso apenas agravará a situação.
Se você não gostar do tom da conversa nos comentários, é melhor encontrar essa pessoa e conversar com ela pessoalmente, para explicar o que não combina com você.
Se isso não ajudar, o Google recomenda entrar em contato com o gerente.
Pela minha experiência, quero acrescentar que muitas vezes uma pessoa que escreve um comentário mal-educado geralmente não fornece uma conta que possa parecer agressiva. O texto esconde metade das emoções; por exemplo, o que é dito em um tom de brincadeira amigável em forma de texto pode parecer um duro atropelamento. Portanto, concordo plenamente com o Google - em caso de mal-entendido, comunique-se apenas pessoalmente!
Explique o código
Se você for solicitado a explicar um ponto no código, considere se você pode corrigi-lo para que seja compreensível sem explicação. Porque se alguém não entende, outros podem não entender.
Resposta aos comentários do revisor
Freqüentemente, quando o trabalho é feito e enviado ao código de revisão, é psicologicamente difícil aceitar o fato de que algo também precisará ser corrigido. Portanto, tente não perceber os comentários do revisor com hostilidade, pense, talvez ele esteja certo, e o código ficará melhor como resultado.
No entanto, se o revisor ainda estiver errado, sinta-se à vontade para escrever sobre o assunto, fornecendo a resposta com argumentos e fatos.
Conclusões
Em geral, como entendi em um documento do Google, o autor do MR deve fazer de tudo para facilitar o revisor; para que o revisor entenda por que o código foi criado, como o código foi criado, deve haver todo o contexto necessário para a compreensão etc.
É inevitável que as divergências sejam resolvidas com o consenso de uma forma profissional educada.
Na próxima edição da Zinc Selling, discutiremos definitivamente este artigo (e muito mais). Portanto, assine nosso podcast , caso contrário, pule a parte divertida!