👨‍👧‍👧 🚣🏽 ⛩️ Revisão de código - aprimorando o processo 🛌🏿 👩🏽‍🤝‍👩🏻 👋🏻

Imagine uma equipe em que a revisão do código não seja conduzida. Os desenvolvedores escrevem código e, sem verificar, fazem todas as alterações no ramo principal. Depois de um tempo, a funcionalidade expande ou os bugs são encontrados, eles retornam ao código-fonte e todas as variáveis são nomeadas com uma letra, não há como seguir a arquitetura e a qualidade não é a melhor. Esse código de baixa qualidade se acumulará e um dia chegará o momento em que, com pouca inovação, o projeto começará a desmoronar: na melhor das hipóteses, o tempo de desenvolvimento aumentará, na pior das hipóteses, o apoio ao projeto se tornará impossível. E isso apesar do fato de que uma vez a tarefa foi concluída e tudo funcionou bem.

Como isso pode ser evitado?A resposta para a pergunta no título é Revisão de código.

A revisão de código é uma verificação de código para erros que melhora a estabilidade e a qualidade do código.

Agora imagine uma equipe em que a revisão do código já esteja em andamento, mas, no processo em que os desenvolvedores juram entre si, a solicitação Pull não é aprovada há muito tempo, as tarefas começam a congelar. O processo desde o início da tarefa até sua aparição no projeto é esticado e, com isso, todo o trabalho é mais lento.

Solicitação de recebimento / mesclagem é uma solicitação à equipe do projeto (pessoa ou grupo de pessoas) para aprovação e aplicação de alterações na ramificação selecionada. Assim que a solicitação Pull é criada, uma discussão do código escrito ocorre antes da aprovação. Alterações podem ser sugeridas durante a discussão. Após a aprovação, as alterações atuais caem no ramo selecionado.

Abaixo estão listadas recomendações para ajudar a acelerar a revisão do código e melhorar sua qualidade.

Dividimos a questão em três partes e consideramos cada uma separadamente:

Parte técnica: como verificar o código e o que procurar ao verificar?
Parte da comunicação: como evitar disputas e reduzir o estresse durante a discussão?
Parte organizacional: o que pode ser feito para tornar o processo de revisão de código eficiente?

Parte 1. Verificando o código

Execute o código do autor em casa

Execute o código por conta própria e veja como as alterações funcionam em conjunto com o restante do código. Isso ajuda a encontrar áreas problemáticas que não são visíveis na interface baseada na Web. Tente ver o código de forma abrangente, evite se concentrar apenas nas alterações locais. Portanto, você descobrirá rapidamente o código e encontrará imprecisões arquiteturais, se houver.

Lembre-se da experiência do usuário

Preste atenção em como as alterações no código afetarão o usuário final. Até o código mais lindamente escrito pode ser inútil para os usuários, o que levará a tarefas adicionais, bugs e também poderá impactar a reputação da empresa e do produto.

Nós olhamos para a lógica geral

Os desenvolvedores podem resolver o problema com êxito, mas interrompem o trabalho de outras partes do código. Para impedir que isso aconteça, observe não apenas como uma tarefa específica está sendo resolvida, mas também como as mudanças afetarão o trabalho de outros serviços, módulos e todo o projeto como um todo.

Nós olhamos para a arquitetura de código

A arquitetura do código determina quanto tempo, no futuro, gastaremos em expandir, adicionar funcionalidade ou editar um bug. Além disso, a arquitetura do código pode afetar a aparência potencial de erros em caso de alterações no projeto. Idealmente, expandir e adicionar novas funcionalidades não deve levar à refatoração.

Nós escrevemos mais fácil

Preste atenção à complicação do código: quanto mais simples o código, mais fácil é ler e mais fácil manter. Livre-se de partes complexas do código.

Multithreading

Se o projeto envolver trabalho em vários encadeamentos, veja o que acontece se houver um atraso durante a execução do código em um dos encadeamentos e como esses casos são resolvidos.

Otimização excessiva

Como escreveu o clássico Donald Knuth, a otimização prematura é a raiz de todo mal. É melhor otimizar apenas o que é necessário aqui e agora.

Descobrimos erros

Preste atenção em como o projeto se comportará se não for possível executar uma linha de código, um bloco de código ou uma solicitação ao servidor. Freqüentemente, os desenvolvedores interrompem a execução de uma função sem saída de erro, mas esses casos precisam ser resolvidos.

Conformidade

O código deve estar em conformidade com o contrato, o estilo do código. A uniformidade do código não é um capricho, mas uma necessidade: esse código é mais fácil de manter e é mais fácil entender esse código.

Nomes e aparência

Lembre-se de outros programadores que terão que entender seu código. Código legível simplifica seu suporte adicional. Os nomes devem ser compreensíveis e descrever com precisão a classe, objeto, função etc.

Comentários do código

Os comentários devem responder à pergunta: “por que isso é feito?”, E não “como isso é feito?”. Lembre-se disso.

Parte 2. Discutimos

A principal regra de discussão: qualquer comentário deve ser direcionado ao código, e não à pessoa que o escreveu. Funciona na direção oposta - não tome comentários como críticas a você pessoalmente. A tarefa da revisão de código é melhorar seu código, porque o que você não notou pode ser percebido por outras pessoas. Os colegas podem propor soluções alternativas, e esse é o potencial de crescimento profissional. É importante lembrar que a discussão do código não é um concurso de humor ou um show de “quem sabe mais”, portanto, sarcasmo, agressão oculta e grosseria são inadequados nele.

Como regra, a solicitação de recebimento é realizada em serviços especiais de hospedagem na web (github.com, bitbucket.org, gitlab.com etc.), onde é possível visualizar as alterações e deixar um comentário em um trecho de código específico.

Cumprimos o contrato

Novamente, o código deve estar em conformidade com o contrato. No entanto, se esse acordo não existir, você não deve pedir a um colega para adicionar um espaço ou recuo no código.
Em momentos polêmicos, você pode concordar com toda a equipe no processo de revisão de código, mas pedir para seguir essas regras é melhor na revisão de código a seguir, para que seja mais fácil para todos aceitá-las. A propósito, uma orientação documentada no estilo de escrita remove quase todas as disputas.

Nós oferecemos uma alternativa

Evite declarações como "você fez errado ...", "por que, por que você escreve assim?" e outros, são vistos como críticas e levam a desculpas. É melhor escrever um comentário sobre o conteúdo do código, sem recorrer à identidade do autor. Tente também evitar ordens e coerção: as pessoas não gostam quando alguém as ordena e percebem esses comentários negativamente.

Você pode proceder da seguinte maneira:

Escrevemos o que há de errado com o código
Por que é melhor não escrever
Oferecemos opções alternativas

Permanecemos dentro da estrutura do problema

Muitas vezes, você pode ver comentários sobre o código anterior e não tocado. Não há necessidade de comentar o que não é relevante para a tarefa. Quaisquer edições de terceiros podem levar muito tempo e serem percebidas negativamente; portanto, é melhor observar como uma pessoa concluiu a tarefa atual e não pedir que refatore o projeto.

Elogio

Se você encontrar uma solução interessante ou interessante, fique à vontade para elogiar. Além disso, é uma grande motivação para seus colegas continuarem a escrever bons códigos no futuro.

Todos os comentários são iguais.

Muitas vezes acontece que um programador sabe tecnicamente mais que o outro, como evidenciado pela graduação de líder de equipe júnior, médio e sênior. Não vale a pena destacar os comentários de um grupo como mais importantes. Isso desvaloriza a opinião de alguns desenvolvedores, o que pode levar à indiferença e participação formal na revisão de código. Quando as opiniões de todos são igualmente importantes, a revisão de código é mais produtiva.

Expresse claramente seus pensamentos

Para uma comunicação produtiva, escreva o mais detalhado possível e explique todos os detalhes. Todo mundo tem um nível diferente de conhecimento, e até agora ninguém aprendeu a ler mentes.

Fazendo perguntas

Fique à vontade para perguntar a seus colegas por que a opção proposta é melhor que a atual. Esta é uma ótima oportunidade para aprender algo novo e crescer profissionalmente.

Resolvemos conflitos

Acontece que uma pessoa não aceita todos os argumentos e não pode oferecer os seus próprios, se recusa a fazer algo. Algumas dicas práticas para este caso:

A maioria das situações de conflito pode ser resolvida falando pessoalmente, em um tom amigável.
Você pode admitir, pois não pode escrever código enquanto está em guerra.
Você pode atrair toda a equipe e decidir juntos a melhor forma de escrever o código.
Na revisão de código atual, deixe tudo como está e faça com que as questões controversas separem tarefas para refatoração, tarefas, porque as palavras “depois consertamos”, como regra, nunca ganham vida.

Parte 3. Melhorando o Processo

Nós descrevemos o que eles fizeram

Descrevemos a essência da tarefa no cabeçalho da solicitação de recebimento (ou fazemos um comentário separado) e quais etapas foram tomadas para concluí-lo.

Divida a solicitação de recebimento em partes

Um grande pedaço será observado por um longo tempo, discutido por um longo tempo e corrigido por um longo tempo. Divida o código em pequenas partes lógicas - dessa forma, o processo será muito mais rápido.

Responder a todos os comentários

É aconselhável responder a cada comentário para que a equipe não tenha ambiguidades. Outros desenvolvedores devem entender que você leu o comentário, fez o trabalho necessário e fez as correções. Abrir constantemente uma solicitação pull e observar o que foi corrigido e o que não é é muito inconveniente e demorado.

Pesquisar tudo?

Existem abordagens diferentes - para procurar o máximo de proveito possível ou primeiro para comentar momentos importantes da arquitetura e, após a correção, preste atenção às pequenas coisas.
Ambos os métodos têm direito à vida. Acredito que a segunda opção consome mais tempo: imagine que após a correção você precise revisar completamente o código novamente, comente e aguarde as correções novamente. É muito mais rápido analisar cuidadosamente o código uma vez, deixar comentários e verificar as correções.
Se houver imprecisões arquiteturais e for claro que pequenos erros desaparecerão após a correção da arquitetura, você não deve perder tempo comentando detalhes nesta seção do código.

Esperando por todos?

Você não pode esperar até que todos aprove a solicitação de recebimento e concorde que a aprovação de 80% dos revisores é suficiente para fechar a tarefa. Isso agilizará a entrada de código no ramo principal, o que é indubitavelmente mais benéfico para os processos de negócios, mas pode levar a discordâncias na equipe e indiferença à revisão do código.

A segunda opção é aguardar a aprovação de todos os desenvolvedores envolvidos. A qualidade do código aumentará, mas o processo em si diminuirá significativamente. A escolha em favor da velocidade ou qualidade, cada equipe deve fazer a sua.

Pequenas coisas

Se não houver comentários sérios sobre o código, não será necessário esperar até que todas as pequenas imprecisões sejam removidas. Eles podem ser indicados nos comentários e aprovar imediatamente a solicitação de recebimento - o autor do código se sentirá mais calmo, sua lealdade à equipe aumentará, ele sentirá que é confiável. E, é claro, a velocidade da solicitação de pull aumentará.

Conclusão

A revisão de código é uma parte importante do processo de desenvolvimento, que afeta o projeto como um todo, por isso é perigoso ignorá-lo. Algumas dessas recomendações ajudarão a acelerar a revisão do código, outras a melhorarão. Espero que minha experiência e conhecimento sejam úteis para os leitores deste artigo.

Revisão de código - aprimorando o processo