Code Review
Talk is cheap. Show me the code – Linus Torvalds
E aweeeeeee meu povo!!!!!
Sei que dei uma sumida, mas realmente de um ano para cá a minha vida virou uma loucura. No entanto, tem sido um ano de bastante aprendizado onde tenho colocado muita novidade em prática — e que pretendo compartilhar mais com vocês.
Em resumo, estou trabalhando em uma nova empresa, AB InBev, e é lá onde tenho tido a oportunidade de colaborar e ajudar a inovar com novas ideias para a área de desenvolvimento. A melhor parte é que ainda tenho trabalhado com SAP, então estamos conseguindo empregar cerimônias e atividades que até hoje muitos profissionais acreditam ser impossíveis — e uma dessas atividades é a de Code Review.
De maneira breve, code review é uma atividade em que uma ou várias pessoas verificam a entrega de um desenvolvedor lendo partes de seu código, buscando garantir a qualidade da aplicação. Entretanto, por mais simples que pareça essa atividade, não é comum vê-la sendo aplicada no dia a dia do time de desenvolvimento, principalmente quando falamos em SAP. Assim, logo abaixo deixo minha percepção e o que temos feito para conseguir executar essa atividade na firma.
É difícil ler o código de outras pessoas
Para quem acompanha o blog há mais tempo, provavelmente já leu os seguintes posts:
O que esses posts têm em comum é o acrônimo RTFM para a frase “Read the Freaking Manual” (a versão não familiar é mais legal, e por isso o Adriano Campanhola é meu ídolo).
Mas o fato é: quantas vezes poderíamos ter evitado passar horas batendo a cabeça com algo se simplesmente tivéssemos lido o manual (ou no caso de desenvolvedores, a documentação em primeiro lugar)?
Para nós, desenvolvedores, isso vai além em nossas rotinas: no nosso caso, o código fonte é, por definição, a descrição mais precisa de como um determinado programa irá se comportar. Salvo comentários imprecisos e nomes enganosos de variáveis , o código fonte é a única forma de documentação tida como 100% precisa.
O que impede o código fonte de ser uma ótima documentação é o fato de ser tão difícil de ler. E isso porquê:
A maioria dos programadores não consegue ler o código com eficiência!
Bizarro né? Posso imaginar um desenvolvedor recém iniciado na área lendo esse meu comentário e pensando:
Mas isso não faz parte do trabalho de um programador?
Por mais estranho que possa parecer, é verdade e há razões para que o seja.
Entrando um pouco mais no detalhe, a minha intenção em ser alarmista se deve ao fato de que quase todo programador pode ler código no sentido mais estrito da palavra, ou seja, pode analisar uma determinada linha de código e ter uma ideia razoável do que o código faz. Ser capaz de entender grandes quantidades de código, seus designs e intenções implícitos, ser capaz de extrapolar e entender como o código evoluirá com o tempo, no entanto, é uma história completamente diferente.
Infelizmente, essas habilidades podem ser raras em muitos desenvolvedores. Em outras palavras, a maioria dos desenvolvedores tem alguma facilidade na leitura de código, mas eles são realmente deficientes na compreensão do código.
Na minha experiência, a parte mais incrível sobre desenvolvimento é que é mais difícil ler o código do que escrevê-lo. Existem algumas razões que, na minha opinião, são as principais responsáveis por esse fenômeno.
O primeiro motivo pelo qual o código é mais difícil de ler do que escrever tem a ver com a enorme quantidade de dados que você precisa manter em mente para ler o código. Ao escrever código, você só precisa lembrar as variáveis, algoritmos, dados e outras informações que somente são relevantes para o recurso que está sendo escrito naquele momento. Por outro lado, ao ler o código, você precisa manter os dados não apenas sobre o recurso que você está investigando, mas também sobre outras funcionalidades potencialmente relevantes.
Algo que busco fazer quando estou entendendo o código é entendê-lo suficientemente bem para aproveitá-lo. Tento sempre criar um modelo funcional do design na minha mente, baseado a partir de pistas sugeridas pelo próprio código.
Entretanto, quando escrevemos o código, muitas vezes podemos ignorar os casos de exceção e erro com a expectativa de alcançá-los assim que a lógica principal estiver funcionando, ao contrário do momento em que estamos lendo o código, onde todos esses casos de exceção e erro já estão implementados e incorporados ao código.
Outro fator relevante que confunde a leitura do código é o orgulho. Orgulho do programador. Escrever código é um empreendimento surpreendentemente pessoal. Quando você passa muito tempo pensando profundamente sobre um problema e criando código para resolvê-lo, pode facilmente se apegar emocionalmente ao código que criou.
Isso pode ser vantajoso porque incentiva os programadores a refinar constantemente seu código favorito, mas também leva os programadores a ter sentimentos territoriais sobre um domínio de problema específico e a inclinar-se em seu próprio código. Esse tipo de orgulho pode tornar extremamente difícil para um programador ler a implementação de outra pessoa e compará-la de maneira justa com a sua. De fato, se eles começarem a ler código com a suposição de que não vão gostar, nunca serão capazes de aplicar a força cerebral necessária para entender o código que deveriam ler.
Sobre esse elemento de orgulho do programador, é sempre excelente manter em mente o seguinte:
Você não pode menosprezar alguém quando lê o código. Se você não respeitar a pessoa que escreveu ou está escrevendo o código, não poderá aplicar a energia necessária para entendê-lo.
Temos, portanto, que a leitura do código é difícil porque pode ser mental e emocionalmente desgastante. Sendo esse o problema, o que podemos fazer sobre isso? Certamente, acredito que o code review seja um conceito excelente para se exercitar.
Por que executar Code Review?
Code review em minha experiência está intimamente ligado à qualidade. Todos sabemos que, quando um desenvolvimento é entregue com muitos defeitos, os desenvolvedores passam mais tempo corrigindo a aplicação do que escrevendo novas funcionalidades. Mas mesmo sabendo disso, alguns (muitos) projetos tentam economizar tempo reduzindo o tempo gasto em práticas de garantia de qualidade como code reviews e testes.
Um outro benefício trazido com a prática de code reviews é que o trabalho é descentralizado em toda a equipe. O time passa a não ter apenas uma única pessoa que conhece uma parte específica da código. Assim, as revisões de código ajudam a facilitar o compartilhamento de conhecimento do código dentro do time.
Falando em compartilhar conhecimento, um aspecto especial é que, quando novos membros se juntam à equipe, engenheiros mais experientes orientam os membros mais novos. O code review ajuda a facilitar as conversas sobre a código. Não é nada incomum encontrarmos conhecimentos ocultos dentro do código que aparecem durante o code review. Os membros mais novos, com novos olhos, descobrem áreas retorcidas e complicadas da aplicação que precisam de uma nova perspectiva. Portanto, o code review também ajuda a garantir que o novo insight seja temperado com o conhecimento existente.
Um último ponto é que quando os desenvolvedores sabem que seu código será revisado por um colega de equipe, acontece uma pressão natural que exige um esforço extra para garantir que todos os testes sejam aprovados e que o código seja tão bem projetado quanto possível para que a revisão ocorra sem problemas. Essa atenção também tende a tornar o processo de codificação mais suave e, em última análise, mais rápido, afinal, você certamente não quer ser o cara que toma o tempo de todo o resto do time por não fazer seu trabalho bem feito.
O que procuro avaliar durante o Code Review
Sem dúvidas, a primeira coisa em que penso quando preciso revisar o código de outro desenvolvedor é no design do que está sendo entregue. Basicamente, pontos como:
- Como o novo código se encaixa na arquitetura geral?
- O código segue os princípios do SOLID, DDD e/ou outros padrões de design que são usados em codificação? São apropriados?
- O contexto do código inserido, está no lugar certo? Certeza que não existe outra rotina que poderia ter sido reutilizada?
- Teste unitário;
- Overengineering YAGNI.
E em seguida eu sigo para legibilidade e manutenção. Assim, procuro sempre ter claro quais são as formatações e estilos aplicados pelo time. Busco analisar o seguinte:
- Descrição de campos, variáveis, parâmetros, métodos e classes realmente refletem o que representam?
- Posso entender o que o código faz apenas lendo-o?
- Além da garantia de que os testes cobrem um bom subconjunto de casos (e não apenas os caminhos felizes), sou capaz de entender o que os testes fazem e, por tabela, o que foi desenvolvido?
- As mensagens de erro de exceção são compreensíveis?
Com a ajuda da descrição do Pull Request (algo que irei abordar mais abaixo), busco entender se o código que estou revisando realmente entrega o valor que a funcionalidade espera, isto é:
- O comportamento do código realmente reflete o que está descrito como premissa do desenvolvimento? Com testes unitários, essa atividade fica muito mais simples, pois os testes deverão refletir exatamente isso.
Não acredito que exista uma única maneira de realizar essa avaliação, entretanto é possível encontrar muitas dicas por ai. Uma delas que eu verdadeiramente recomendo é a seguinte:
Quais cuidados costumo ter — como desenvolvedor — durante a submissão de código
Sem dúvida alguma minha maior preocupação está em escrever uma documentação e, para isso, utilizamos a pull request. Na minha experiência, essa é a chave para que os revisores não desistam do seu código.
Além disso, é também a chave do sucesso durante o code review. Justamente por isso, quero trazer aqui exatamente o que temos como boa prática sendo executado atualmente na "firma", para que fique claro que isto é algo que pode ser aplicado no dia a dia.
Pull requests são uma ótima maneira de introduzir novas alterações em um repositório por meio de revisão e/ou discussões sobre as alterações que você deseja enviar.
O Pull Request — Depois de ter finalizado o desenvolvimento na sua branch (no nosso caso utilizamos como estratégia de workflow feature branch), você já está pronto para ir até o repositório — que no nosso caso é o Azure Repos — e criar um novo pull request no repositório em que está trabalhando.
Um ponto muito interessante é que você sempre pode mencionar outros usuários e equipes para solicitar feedback ou novas idéias e trazer pessoas de fora do projeto para contribuir na discussão atual.
Template utilizado por nós para abertura de um Pull Request
O título do PR deve ser nomeado usando o seguinte formato:
#[STORY_ID] Descrição da história
Get Erick Carvalho’s stories in your inbox
Join Medium for free to get updates from this writer.
A descrição do pull request deve conter os seguintes títulos e o conteúdo correspondente no formato Markdown.
- O que esse pull request faz?
- Descrição da tarefa a ser concluída;
- Como isso deve ser testado manualmente?
- Quais são as histórias relevantes à respeito ao contexto desenvolvido?
- Screenshots (se apropriado).
Boas práticas
Normalmente pull requests suportam:
- Markdown;
- Screenshots;
- GIFs.
Então abuse desse tipo de recurso.
Como eu costumo executar um code review sendo um revisor
Eu sempre começo com um checklist preparado antes do início da análise (talvez por ter uma satisfação pessoal com riscar atividades quando prontas — para quem me conhece ou já trabalhou próximo de mim, sabe que utilizo esse hábito para aumentar dopamina).
Com uma lista bem estruturada sobre o que tenho como objetivo de avaliação, eu procuro não analisar mais de 250–300 linhas de código. Além disso, procuro não estender a análise por mais de 60 minutos (no meu caso é por questão de cansaço mesmo).
Por último, mas certamente não menos importante, code review eu vejo na maioria das vezes como uma forma de desenvolver parcerias, por isso é sempre muito importante:
- Ser gente boa e ser claro, nada de sarcasmo ou ironia em comentários;
- Sempre procuro justificar o meu raciocínio;
- Procuro ter certeza que estou servindo apenas como um guia a respeito do que necessita ser ajustado, isso porque a responsabilidade de ajustar o código é de quem submeteu o código, e não do revisor;
- Garantir que não estou submetendo o outro desenvolvedor a algum tipo de exame. O meu papel é garantir que o código melhore, não tem a ver com aprovar ou reprovar o trabalho de alguém.
Code review — Fluxo
Aqui a intenção é apresentar como nós lá da firma temos feito para executar essa atividade (lembrando que ela não é mais certa que outras). Existem algumas formas de realizar essa atividade, principalmente porque existem diversas ferramentas para alcançar o mesmo resultado.
Vou começar apresentando o fluxo que temos trabalhado com desenvolvimentos fora do SAP:
A ferramenta que utilizamos como repositório GIT é o Azure Repos, de modo que não existe muito segredo. Finalizado o desenvolvimento em sua branch, temos o seguinte fluxo:
Dentro do SAP é necessário realizar alguns passos a mais. Por conta disso, vamos começar tentando entender primeiro o fluxo:
A ferramenta que utilizamos para realizar o code review é, novamente, o Azure Repos, isso pois quando realizamos um commit utilizando o abapGit, o código é enviado para o Azure Repos. Dessa forma podemos controlar para que apenas aconteça a liberação da request ou um transporte de cópia de uma task a partir do momento em que todas as tasks tenham tido um code review com os seus devidos revisores.
Isso é importante pois hoje temos a automação e a possibilidade de designar algum revisor específico de maneira dinâmica a partir do tipo de objeto que está presente na task. Exemplo: temos hoje um time que cuida para que a cada objeto de autorização criado no SAP, exista uma role atribuída a ele. Assim, temos o controle de que toda vez que uma task é liberada, caso ela possua um objeto de autorização, automaticamente no code review é adicionado alguém do time responsável para auxiliar na revisão.
O fluxo acima, em movimento:
Abaixo segue um material sobre uma outra forma de executar a integração SAP e Azure DevOps. No meu caso o pipeline de integração contínua (CI) é um pouco diferente. Caso seja do interesse de vocês posso trazer como temos feito também o CI no nosso time.
One Size Does Not Fit All
Sem dúvidas seria maravilhoso se agora, ao final desta publicação, eu tivesse uma formula mágica de como executar o code review perfeito. Entretanto, como sempre, a resposta sobre "Como realizar um bom code review é”:
#Depende
Isso porque:
- depende da equipe;
- depende da aplicação;
- depende do que você está tentando alcançar com o seu código;
- depende da experiência dos envolvido(s) no momento da revisão;
- depende do propósito;
e assim por diante…
Conclusão
Code review é uma atividade que não é simples e exige prática. Nesta publicação tentei trazer o máximo de minha experiência nesse assunto sobre padrões que procuro empregar para tornar a experiência do code review mais proveitosa e agradável.
Para finalizar, alguns padrões que eu tomo muito cuidado, e que em minha experiência sempre se mostraram não ser efetivos durante a rotina de code review, são:
- Revisão com banca examinadora de babacas — Nunca passei diretamente por essa situação, entretanto estive muito próximo de times que utilizavam essa abordagem. E aqui o que existia era uma banca formada pelos "donos do produto", e o prazer deles era servir como juízes de algum reality show, onde a graça está em ser irônico/sarcástico/superiore a quem está submetendo o código para revisão. O resultado, é claro, era apenas a auto-estima lá embaixo e ressentimentos. Um detalhe é que nessa situação estou falando de uma banca de babacas, mas existem situações onde basta um babaca que seja o dominante, e teremos a mesma a situação de merda.
- Maratona de revisão — Essa é uma situação que já passei algumas vezes. O que tínhamos eram horas sentados em uma sala, revisando todo o código. Já tive situação de quase 10 horas de revisão direto. Claro que isso não foi proveitoso, por mais que começássemos muito empolgados com a revisão, depois de algumas horas, é impossível manter a qualidade.
- Falta de guias de boas práticas de desenvolvimento — O grande ponto aqui é que se o time não possui um guia de boas práticas, muitas vezes o time fica refém do bom humor de quem está revisando, isso porque um dia pode ser que a utilização de classes estáticas seja uma coisa aceitável, entretanto na semana seguinte é algo terrível. Esse tipo de falta de padrão desgasta o time, por isso vale bastante a pena que seja investido um tempo na definição das boas práticas. E vejam, nada impede que elas mudem, entretanto elas precisam estar claras para todos.
- Fingir code review —Você submete o seu código para revisão e, após 5 minutos, recebe um e-mail que o código foi revisado. Nem preciso dizer o quão desperdício de tempo é possuir um processo que o próprio time sabota, certo?
Para evitar qualquer tipo de situação como essas, sempre estabeleça o objetivo do code review. Novamente, um code review pode ser quebrado em diferentes contextos como: qualidade do código, segurança, design e etc…
Então muito obrigado pela atenção e companhia em mais esse post.
Não deixe de conferir as referências abaixo, e se curtiu o post não deixe de participar comentando, compartilhando ou simplesmente segurando esse botão de aplausos para mostrar que é esse tipo de conteúdo que você deseja ter por aqui. Muito obrigado e até mais!
