Revisão de código - O Caminho do Samurai

[Slide 2] Olá, me chamo Guilherme Cordeiro e sou Desenvolvedor Android no Luizalabs

[Slide 3] Os Samurai, denominação dada aos homens, e Onna-bugeisha, no caso das mulheres, ficaram bem conhecidos como destemidos guerreiros com um rígido código de honra e conduta, denominado Bushidô. Mas o que é menos sabido é que entre eles (e elas) estavam alguns dos mais dedicados estudiosos das artes, literatura e até filosofia do Japão de sua época.

[Slide 4] Inclusive algumas formas de arte como o Ikebana (que é a arte dos arranjos florais) e a Chanoyu (também conhecida como chadô, ou cerimônia do chá) eram também consideradas artes marciais, pois treinavam as mentes e as mãos dos praticantes. Focar só no combate não era suficiente, era preciso desenvolver também as outras áreas de conhecimento, pois cada uma delas os preparava para algum aspecto de sua vida. Nessa busca, descobriram o Zen-budismo, como um caminho que conduzia à calma e à harmonia.

[Slide 5] Nós programadores passamos boa parte do nosso tempo de estudos focados nas melhores arquiteturas, novas tecnologias e bibliotecas padrão de mercado. Mas será que damos a devida atenção e valor para as revisões do código que nós mesmos escrevemos?
Será que muitas vezes não encaramos essa etapa do processo de desenvolvimento como burocracia, como algo que atrasa nossas entregas e nem sempre se mostra eficaz em evitar bugs e código ruim? Então porque fazer, se já escrevemos testes unitários, de interface, de integração? Se temos lint, findbugs, codestyles?

[Slide 6] Definição: Prática de submeter novo código à revisão de pares antes de mergeá-lo no master do repositório.

[Slide 7] Formal ou informal: A revisão de código pode passar por um processo formal, com metodologias, métricas e ferramentas ou por um processo mais informal, onde os desenvolvedores interagem de forma mais próxima e direta. Não vou me aprofundar no primeiro caso, até porque tenho pouca experiência com ele. Também não sou nenhum especialista no processo informal de revisão, meu objetivo desta palestra era justamente me botar para estudar um pouco mais, onde ainda falho no processo e dividir um pouquinho do que aprendi com vocês. Pra o propósito desta palestra vamos discutir revisões informais simples do estilo Pull Requests que serão mergeados após o joinha do revisor. Se cada PR passa por um ou mais revisores não faz tanta diferença aqui e depende do combinado dentro de cada time.

[Slide 8] Diferentes objetivos: Cada time pode ter também objetivos diferentes com o processo de revisão de código, e o mais importante é que todos estejam alinhados no que é esperado. É só verificar se não há furos na solução? Se os testes não quebram? Se há testes, o código está limpo e bem escrito, fácil de dar manutenção? Uma possível boa prática é estabelecer um checklist, para guiar o revisor e informar ao autor do PR o que é esperado dele.

[Slide 9] Compartilhar conhecimento: A revisão de código é uma boa oportunidade para ambos os lados. Quem escreveu aprende com os pontos levantados por quem revisa. E quem revisa se intera de uma funcionalidade do sistema que talvez não conhecesse a fundo. É fundamental evitar que o conhecimento de certa parte do sistema esteja na cabeça de uma única pessoa (em especial se essa pessoa deseja tirar férias). O processo de revisão de código é uma oportunidade de desenvolvimento de mão dupla, pois ler o código de outras pessoas é uma excelente forma de aprendizado.

[Slide 10] Validar ideias por diferentes pontos de vista: Muitas vezes ao resolver um problema não pensamos por todos os ângulos possíveis, e nada como alguém olhando de fora para achar aqueles corner-cases que não levamos em conta.

[Slide 11] Validar facilidade de entendimento e manutenção: Um código bem escrito tem que estar claro não só para quem o escreveu, afinal, nem sempre vai ser você a dar manutenção aquele código.

[Slide 12] Identificar problemas*: A revisão de código pode ajudar a evitar que alguns bugs sejam introduzidos, mas essa é uma das utilidades mais questionáveis, afinal em teoria os testes automatizados e QA já tem essa função. A principal função do revisor é identificar problemas na SOLUÇÃO. Coisas que quem escreveu não pensou, tratativas faltantes, corner-cases...

[Slide 13] Ao terminar uma tarefa é normal termos a urgência de querer ver nosso código mergeado o quanto antes. Até porque temos constantemente a pressão de entregar logo e muito provavelmente já temos mais alguma tarefa para começar na sequência… E ninguém gosta de ficar fazendo rebase. Fazer rebase é que nem pagar juros, quanto mais postergamos mais enrolados ficamos e maior a chance de dar ruim. Nesse ponto é normal que fiquemos aflitos com o processo de revisão. Mas se fizermos direito o nosso papel, podemos mitigar muitas das dores do processo, e até crescer profissionalmente com ele.

[Slide 14] Fornecer contexto: quem está revisando pode não estar familiarizado com a feature em questão, problema a resolver ou mesmo com o projeto. Seja claro no problema que está resolvendo, explique o fluxo no qual ele acontece, e o que você fez para resolver. Se necessário forneça prints ou se prontifique a explicar rapidamente por chat em pessoa. Forneça um executável para facilitar os testes quando relevante.

[Slide 15] Revisar antes de commitar: Não precisa nem dizer né? A responsabilidade de achar bugs, lints, falhas de estilo e formatação, código não utilizado ou comentado é sua, o revisor é apenas uma segunda verificação de segurança. É uma boa prática reler todo o código antes de commitar, ou pelo menos rever seu próprio pull request antes de pedir que outros revisem.

[Slide 16] Se atentar ao tamanho dos PRs: Essa é uma equação bem difícil de fazer. Seu PR não deve se prolongar demais, ou a revisão dele será difícil e demorada (e provavelmente despriorizada). Por outro lado, mandar diversas modificações seguidas no mesmo trecho de código, fazendo o revisor passar muitas vezes pelo mesmo contexto ou revisando código que ainda vai ser refatorado também não é legal. O segredo é tentar focar numa parte da mudança por vez e tentar arredondar ela até o final, de preferência com testes. Aquiteturas que dividem sua aplicação em camadas facilitam esse approach. Outro dica importante aqui é o TIMMING dos PRs. Se você também revisa PRs dos outros membros do time, as vezes pode ser uma boa prática tentar coincidir mais ou menos o timing dos PRs, pois assim ambos os lados podem sair com um pouquinho mais de calma de seus contextos e focar na revisão.

[Slide 17] Valorizar o tempo do revisor: O tempo dele é tão importante quanto o seu. Pense que ele está lhe ajudando, e não trabalhando para você. Então tudo que der para resolver você mesmo, faça antes da revisão.

[Slide 18] É fácil cair na armadilha de somente apontar aquilo que você não concorda no código dos outros e mesmo dizê-los o que devem fazer. Além de promover conflito (quem é você para dizer aos outros como eles devem fazer o trabalho deles), existe a possibilidade de você não ter entendido o porque aquilo foi feito daquela maneira. Será que quem escreveu aquele código não considerou previamente o que você iria sugerir mas por algum motivo escolheu fazer diferente? Será que o modo com que o problema foi resolvido não está também correto, só não é o jeito que você faria?

[Slide 19] Seja humilde e encorajador: Mesmo que você esteja certo do seu ponto, o modo que você o comunica deve sempre ser voltado a ajudar a resolver o problema, nunca para provar que você sabe mais. Cuidado para não apenas apontar o erro mas sem oferecer uma solução. Se possível, invés da solução ajude quem escreveu o código a pensar melhor e dê um empurrãozinho na direção que você acredita que seja mais correta. É importante que cada um se sinta capaz de fazer seu trabalho, sem a constante preocupação do que será apontado na revisão.

[Slide 20] Use o método socrático: Sócrates, mestre de Platão e considerado um dos fundadores da filosofia ocidental, iniciou sua jornada filosófica quando ao visitar o Oráculo de Delfos ouviu de uma de suas sacerdotisas que o fato de ele não saber nada o tornava o homem mais inteligente do mundo. Em todas as ocasiões, Sócrates não emitia nenhuma afirmação apenas fazia novas perguntas. Sócrates tinha convicção de que eram os diálogos que favoreciam uma verdadeira troca de conhecimento, pois através deles os discípulos conseguiriam refletir sobre suas próprias afirmações e conclusões.
Ao invés de comentários como “mude isso” ou “está tudo errado refaça”, pergunte para instigar o debate. Use perguntas como “não seria mais interessante trocar esses nomes para ganhar mais significado?”, “não acha que essa classe possui responsabilidades demais? E se seguíssemos a ideia do SRP?”. Essas perguntas vão forçar o autor a pensar sobre sua implementação para conseguir argumentar e defendê-la.

[Slide 21] Terceirize as críticas: Se possível deixe que ferramentas de revisão automáticas cuidem das críticas mais chatinhas, do tipo formatação, cobertura de testes, padrão de nomes… Isso poupa tempo no bate-volta das revisões além de desgastar menos a relação entre os membros do time…

[Slide 22] Não assuma saber: Antes mesmo de começar a revisão, converse se preciso com quem escreveu o código, garanta que você entendeu o contexto, ou peça que te explique rapidamente. Isso pode economizar tempo que você gasta tentando entender o que foi feito, pode trazer a tona informações que você não sabia (afinal, não foi você que gastou mais tempo tentando entender e atacar o problema) além de iniciar um diálogo, que pode fortalecer as relações do time.

[Slide 23] Disponha-se a ajudar: Avaliar algo é fácil, porém, muitas vezes a pessoa pode levar um bom tempo para absorver a nova informação. Por isso é bom explicar pessoalmente o porquê de alguns comentários e também oferecer ajuda para resolver as pendências. Mas isso só deve ser feito quando houver real necessidade, e quando a pessoa aceitar a ajuda. Muito cuidado com o mansplanning.

[Slide 24] Assuma co-responsabilidade: Se um código que você revisou der problema em produção ou mesmo durante o QA, insista em tomar responsabilidade publicamente também. Quem escreveu o código já vai estar sobre a pressão de ter que corrigir o problema, e saber que pode contar com você pra dividir a bucha não só fortalece o relacionamento como time, como demonstra atitude de dono.
Uma última dica é se possível manter curtas as sessões de revisão. Se você tentar revisar muita coisa de uma vez, é comum perder o foco e começar a ler o código mais superficialmente .

[Slide 25] Sim, essa história de samurai e onna-bugeisha foi um pouco click-bait, assumo, mas eles também foram uma ilustração de como é importante a gente estar pensando fora da caixa, a não seguir nossos papéis limitados a definição mais estreita deles.
Por um lado, devemos estar abertos aos questionamentos, analisando cada sugestão de forma lógica e nunca levando nada para o lado pessoal, se dispondo a aprender com os nossos erros e as experiências dos demais.
De outro, entender que tentar fazer o trabalho dos outros ou se julgar no direito de ditar o modo correto de fazê-lo só serve ao nosso ego, e nunca ao interesse do produto ou ao propósito de desenvolver o time.
Excelência técnica é uma qualidade nobre e desejável, mas no final do dia ainda somos pessoas interagindo com pessoas, e é muito mais importante um time que saiba interagir bem e trocar de forma saudável entre todos os níveis do que um time cheio de talentos individuais, mas que não criam um ambiente de cooperação onde haja oportunidade para todos se desenvolverem.

[Referências]
https://medium.com/@tadasant/theres-a-human-on-the-other-side-of-your-code-review-9732cc15bfee
https://www.youtube.com/watch?v=PJjmw9TRB7s&index=2&list=LLd_50AreJiQvwohSFlvH99w
https://medium.com/trainingcenter/qual-e-meu-papel-durante-o-code-review-a9056dee1b23
https://labs.getninjas.com.br/code-review-comunicação-amigável-e-cultura-ba0c12bc3ccb
https://blog.asana.com/2016/12/7-ways-to-uplevel-your-code-review-skills/
https://www.infoescola.com/pedagogia/metodo-socratico/
https://pt.wikipedia.org/wiki/Samurai

Obrigado!

Questões? Opiniões? Sugestões?

GUILHERME CORDEIRO
[email protected]
[email protected]

E um muito obrigado a minha "marida" Melissa, que me ajudou na revisão e fez todo visual bonitoso da apresentação 💕