Como engenheiro de software júnior, sempre examinei comentários de revisão de código que recebi para aprender como me tornar um codificador melhor. Mas quando chegou a hora de tentar minha primeira revisão de código, percebi que minha experiência não me preparara para estar do outro lado.
Eu desenvolvi um caso grave de síndrome do impostor, em espiral descendente com perguntas: Devo comentar sobre esta linha de código ou não vale a pena? Devo encontrar artigos para apoiar todos os comentários? Vou deixar o site aprovando isso? Eles vão me odiar? Ok, eu admito que eu espiral muito rapidamente. Mas depois de falar com alguns colegas de trabalho, eu sabia que não estava sozinha em minhas preocupações.
Engenheiros de software júnior podem ser lançados na revisão de código com uma suposição análoga a "você sabe ler um livro para saber como escrever um livro, o que não é verdade", diz Jessica Rudder, engenheira de experiência do GitHub.
Existem expectativas que vêm com a revisão de código, e o processo pode ser estressante. Então eu entrevistei sete outros engenheiros de software para coletar dicas sobre como construir uma mentalidade de revisão.
1. Pense sobre o impacto geral
Geralmente, um bom pedido de solicitação (PR) deve afetar apenas uma parte confinada da base de código. No entanto, o escopo limitado não deve impedi-lo de pensar sobre a alteração do código dentro do contexto da base de código maior.
Nigel Munoz, ex-engenheiro de stack completo da The Muse e atual engenheiro de software freelancer, incentiva o revisor a pensar em “como essa mudança afeta a imagem cada vez menor”. Considerando o quadro mais amplo, encontramos alguma dívida técnica - procure código que é repetido, não modular ou não adere às convenções padrão mais recentes, além de analisar modificações na arquitetura da base de código.
Sam Donow, um dos principais desenvolvedores da Hudson River Trading, acredita que “não há nada muito grande ou pequeno demais para comentar. Sugestões para pequenas melhorias podem levar a melhorias maiores em várias partes da base de código. ”
Você pode usar um comentário PR no GitHub para fornecer feedback positivo, bem como indicar onde o código pode diferir das convenções padrão da estrutura React.
Por exemplo, durante uma das minhas próprias revisões de código, recebi um comentário de que certas propriedades em um componente React eram confusas, o que provocou perguntas mais amplas sobre como o componente estava sendo usado. Por fim, removi as propriedades do componente original e criei um componente separado para esclarecer o comportamento de cada um e garantir que ambos pudessem ser usados em mais lugares.
2. Considere a segurança
Não se esqueça de que algumas alterações podem afetar mais do que apenas a base de código. O Rudder recomenda avaliar se um usuário “poderia usar essa funcionalidade para assediar alguém ou abusar do sistema”. Por exemplo, se o novo recurso na solicitação pull incluir entrada do usuário, procure SQL injection, acesso a dados, cross-site scripting e outras vulnerabilidades de segurança.
3. Concentre-se em erros
Seus colaboradores do código - não importa o quão robóticos eles possam parecer - são humanos, e os humanos podem quebrar ou esquecer as funcionalidades. Portanto, certifique-se de “rever os testes com a mesma importância que o resto do código”, aconselha Abhishek Pillai, um líder de tecnologia na Teachers Pay Teachers. "Eles evitarão novos bugs e servirão como uma forma de documentação para qualquer outra pessoa que trabalhe nisso no futuro".
A leitura dos testes pode ajudá-lo a entender a funcionalidade de um novo recurso e ver os diferentes casos que ele irá apresentar, enquanto a análise dos testes pode ajudá-lo a apontar casos ausentes e encontrar recursos não contidos neste PR. Se não houver testes incluídos na alteração do código e eles parecerem relevantes, é apropriado solicitá-los na revisão.
Mas testes não são tudo. "Não confie demais no sistema", adverte Donow. "Só porque os testes foram executados não significa que não haja bugs."
Você também pode querer “executar o aplicativo localmente para testá-lo funcionalmente e garantir que ele funcione. Se isso não funcionar, então não há sentido em continuar analisando ”, diz Ryan Verner, desenvolvedor de software da 8th Light. Embora alguns revisores não achem que o teste manual deva fazer parte do processo de revisão de código - em parte devido ao tempo necessário - Verner acredita que é uma maneira rápida de determinar se você deve investir mais tempo e uma estratégia para ajudar a restringir o crescimento de um backlog de bugs.
4. Seja um jogador de equipe
O clichê assume um novo significado quando se trata de rever o código. "Reserve um tempo para analisar, porque é a base de código de todos", diz Verner, que defende um senso de "propriedade coletiva". Você, como revisor, deve estar trabalhando para proteger o acúmulo de bugs de crescer com o objetivo de dar a sua equipe menos trabalho abaixo da linha.
Pillai usa gifs para celebrar seus PRs aprovados e prontos para serem fundidos.
Ao mesmo tempo, Charles Luxton, um líder de tecnologia da The Muse, incentiva o revisor a entender e lembrar as prioridades da equipe. Com prazos e desentendimentos que se aproximam rapidamente, às vezes criando um item de tarefa para o backlog que garante melhorias serão feitas no futuro e colocar um comentário sobre o código em questão enquanto isso é o Band-Aid que você precisa para mantenha sua equipe feliz.
Por fim, perguntar a si mesmo se o código faria sentido para alguém que acabou de ingressar na equipe e o estava lendo nas primeiras semanas ajudará a manter seu código legível e compreensível.
5. Use o processo de aprendizado e compartilhamento de conhecimento
O processo de revisão dá a todos os envolvidos um lugar para obter mais informações sobre a base de código, idiomas, estruturas e práticas recomendadas.
Matt Jeffery, um líder de tecnologia da The Muse, aconselha o revisor a "entender as mudanças arquitetônicas. Uma maneira é ler nomes de arquivos, pois eles ajudam a contextualizar. Por exemplo, se você está olhando para uma mudança na camada de acesso a dados você sabe que não está lidando com lógica de negócios ou interface do usuário. "
Você pode usar um comentário PR no GitHub para compartilhar a documentação.
Quando você aprende com alterações de código, também tem a oportunidade de compartilhar conhecimento. "É melhor explicar sua opinião e fazer o backup com documentação", diz Luxton. Os links que você fornece para dar suporte a evidências e artigos confiáveis não apenas ajudam o revisor e o analista de código a explorar diferentes abordagens à medida que tomam uma decisão final, mas também reforçam seus conhecimentos de programação.
Enquanto você mantiver essas dicas em mente, lembre-se também que a revisão é um momento para exercitar suas habilidades pessoais. “Dê às pessoas o benefício da dúvida de que elas pensaram sobre sua abordagem e apontam diferentes possibilidades enquanto tentam desfazer a defesa”, diz Rudder. “Eu deixo comentários por toda parte e um comentário final - aqui está o que é ótimo, aqui está o que pode ser melhorado, aqui está o que precisa ser alterado antes da fusão.”
Com esse tipo de abordagem, você não apenas estará protegendo sua base de código de dívidas de tecnologia, ameaças de segurança e bugs, mas também estará construindo sua equipe.
