Open in app

Sign in

Write

Sign in

Vamos falar sobre cultura de qualidade de software e Code Review?

Gustavo S. Rodrigues
8 min readJun 11, 2020

--

Afinal é possível implantar uma cultura de code review horizontal? É possível ter entregas com qualidade e agilidade? É possível fazer o time de QA e Devs se respeitarem e se ajudarem?

Sim é possível, e mais do que isso, funciona, a pedra angular desse relacionamento está diretamente relacionada a cultura do time, e não é tão complicado mudar, desde que todos assumam que são vulneráveis, ou seja, todos sem exceção podem e vão falhar, e essas falhas não podem ter identidade, ou seja, não precisamos perseguir culpados, precisamos perseguir a solução e como não cometer os mesmos erros.

Assim como em postmortem, uma análise de código ou funcionalidade deve ser impessoal, sugiro inclusive não se atentar a quem fez e sim o que foi feito, porquê foi feito e como foi feito. Isso é fundamental para uma cultura saudável de qualidade, seja no code review ou na correção de um bug da feature que foi criada.

Estabeleça acordos!

“Tudo é negociável. Se é ou não uma negociação fácil, é outra coisa.”, Carrie Fisher

Fiz uma lista de acordos e recomendações que vivenciei e que fizeram a diferença aos longos desses anos para estabelecer uma cultura de qualidade. Veja abaixo processos e acordos que podem ajuda-los a construir essa cultura:

Em sequência alguns dos acordos mais importantes que adotamos:

  1. Todos passam pelos mesmos crivos de validação e isso é irrevogável;
  2. Todo Code review tem que explicar o que, porquê e como;
  3. Um Pull Request deve ter apenas uma correção ou melhoria;
  4. Não tente avaliar algo que uma máquina avaliaria melhor que você;
  5. Faça testes unitários, isso pode ser mais barato do que você imagina;
  6. De autoridade e espaço para os QAs.

Todos passam pelos mesmos crivos

Não tão óbvio mas extremamente importante para estabelecer uma cultura de confiança e qualidade em primeiro lugar.

Isso reforça o senso de que todos são donos do projeto, e que todos são guardiões desse código, afinal, nem o mais sênior, arquiteto ou o papa do time tem o direito de violar essa regra.

Essa abordagem em primeira análise evita decisões prematuras ou problemas estruturais nos projetos, digo isso pois a maioria dos problemas que vivenciei se deram justamente por pessoas que se julgavam superiores às outras e entregava o seu sem avaliação do time, e o preço disso a longo prazo é alto d+, além disso, um bom processo de análise de código ou entrega tende a reduzir o esforço de repasse, visto que todos veem e colaboram com a evolução desse projeto, e em último análise isso economiza um tempo valioso na hora de redistribuir os projetos, além de reforçar uma tendência de padronização natural dos códigos e bibliotecas, ou seja, menor tempo também na criação de novos projetos, pois naturalmente o time se preocupa com o reuso do que faz.

Todo Code review tem que explicar o que, porquê e como

Sempre digo que um bom PR deve ser auto explicativo, deve contar uma história com 3 atos, onde descrevo inclusive minhas motivações e pontos relevantes para quem vai analisar. Por aqui adotamos o modelo abaixo.

Esse modelo deve responder 3 coisas:

  1. Qual problema estou resolvendo?
  2. Por que decidi seguir com o caminho X sendo que o Y também seria possível?
  3. O que é importante ressaltar?

Qual problema estou resolvendo?

Descrição do problema que pode ser de negócio, de falta de indicador ou ainda por critérios técnico como performance, falhas etc.

Essa descrição não pode deixar dúvida sobre o que você está resolvendo e mais do que isso, induz naturalmente a ter PRs incrementais, pois fica muito difícil justificar um ajuste muito grande em um único PR.

Por que decidi seguir com o caminho X sendo que o Y também seria possível?

Essa pergunta é muito difícil de ser respondida se quem fez o PR não analisou todas as opções antes de tar uma decisão, ou ainda se a pessoa compreendeu o problema que está resolvendo.

Claro que você não vai discorrer num PR de atualização de versão de segurança de um pacote, mas é importante que se esforce em analisar e por as justificativas da decisão técnica, isso ajuda a avaliar muitos pontos, antes mesmo de revisar o código em si.

O que é importante ressaltar?

Esse trecho deixo para colocar alguma restrição, risco ou ainda urgência desse código, e isso ajuda a negociarmos a entrega.

Afinal o fato de termos regras e guardiões do código, temos que negociar, mas isso de forma democrática e com acordos de próximos passos, caso seja uma violação das regras previamente definidas, como por exemplo cobertura de teste vs pressão do solicitar para entrega, nesse caso não deixamos de entregar, mas damos o risco na mão de quem solicitou, e obviamente se torna um acordo consensual e transparente.

Um pull request deve ter apenas uma única correção ou implementação

Uma regra importante que temos é sobre um PR deve resolver apenas um problema, ainda que pra resolver um problema maior exija um conjunto de mais ajustes e consequentemente mais PRs, e isso é possível releases maiores ou feature branches âncoras.

Esse acordo nos ajudou a fazermos entregas menores e mais fáceis de validar, pois restringimos um PR por problema, reduzindo o acoplamento da solução, e ajudando o time em toda trajetória de uma entrega maior, e isso de modo geral nos ajudou a nos tornarmos mais ágeis, expondo mais o quanto cada um contribuiu numa sprint, coisa que antes disso era muito subjetivo, quando não, impedia a gestão de saber ao certo em que passo esse projeto está, ou o quão complexo esse ajuste foi.

Não tente avaliar algo que uma máquina avaliaria melhor que você

Automatize o que você pode automatizar, isso economiza um tempo considerável, pois nada será tão justo quanto uma análise automatizada, seja para indicar code smells ou cobertura de testes, e hoje existem dezenas de integrações com serviços de análise estática como o code climate ou o Sonar, que já cobrem boa parte desse tipo validação, isso te dá mais tempo e foco na revisão da implementação e na regra em sí.

Faça testes unitários, isso é mais barato que você imagina

Esse é sem dúvida onde você ganha qualidade na implementação e segurança, embora seja também o ponto de maior atrito cultural, pois se o time não está habituado, haverá resistência das mais diversas formas, a primeira é sobre urgência e cobrança, que nem sempre é inegociável, isso ocorre pois o time tende a por empecilhos em algo que vai num primeiro momento aumentar o tempo de análise e desenvolvimento e é natural nesse momento surgirem atritos.

Recomendo fazer muitas rodadas de treinamento, definir um padrão de teste e uma cobertura mínima é um bom ponto de partida, por exemplo, hoje em código legado, exigimos que ao menos a implementação da feature ou bug tenha cenário de teste e cobertura, ainda que originalmente o projeto não tenha teste unitários, e isso reduz problemas de mais inclusive em projetos mais legados, pois naturalmente o código ficará menos acoplado, pois força o desenvolvimento a fugir de armadilhas de classes com muitas responsabilidades, ainda que em um projeto legado. Esse foi um dos segredos que nos fez ter sucesso nas mudanças que adotamos no time.

Há práticas por exemplo de PR onde o avaliador faz um commit de um cenário de teste que quebraria, melhorando a contribuição e colaboração nesse momento. E com o tempo algumas das discussões técnicas começarão com revisão dos cenários mapeados, antes mesmo da implementação, mas isso não é do dia pra noite, mas insista pois do ponto de vista de código, isso gera menor acoplamento, que por sua vez facilita a manutenibilidade do código, outro ponto relevante é que terá menos riscos nas entregas, visto que força a compreensão e revisão dos cenários de negócio, que por sua vez reduz o risco de falhas em produção.

De autoridade e espaço para os QAs

Sobre o papel do QA no time, esse papel é muitas vezes subestimado, e se não tratado com o devido protagonismo e tempo pra fazer as coisas, sempre fará testes manuais.

No nosso time, passamos a ter na sprint projetos de automação correndo em paralelo com as entregas, e aos poucos foi tomando forma até que tivemos uma cobertura funcional que nos fez gastar menos tempo com testes e cenários massivos, além disso hoje podemos nos orgulhar de ter 80% dos bugs descobertos e tratados ainda em homologação. Isso por si só é uma entrega de valor inestimável, em última análise evita um desgaste com nosso cliente final.

Outro ponto relevante é que optamos por testes integrados usando a mesma linguagem que usamos nos projetos no caso JS e TS, então é algo que os devs também fazem code review, e podem contribuir, além de aprenderem com a implementação.

Considerações finais

Implantar uma cultura de qualidade não é fácil, é um processo longo, que vai passar muitas resistências, por vezes do negócio, dos gestores, até mesmo dos devs. Por isso recomendo por mudanças estratégicas e progressivas, igual, a primeira mudança que fizemos foi ter um guia de avaliação de código é um template, depois nos projetos novos passamos a exigir testes unitários mas sem um padrão definido, para que todos pudessem fazer, e depois adotamos um padrão, fizemos treinamentos é mais treinamentos, trocas e pairs a perder de vista até se tornar algo maduro, o mesmo pra automação de testes integrados, onde foi preciso abrir mão de testes manuais em alguns momentos, de ter a automação como projeto, e agora colhemos os frutos disso, e queremos ir além, já vemos algumas oportunidades antes imperceptíveis de melhorias significativas no processo.

Dicas de leitura:

QA
Dev
Agile
Leadership
Productivity

--

--

Gustavo S. Rodrigues

Written by Gustavo S. Rodrigues

123 Followers

Sou um arquiteto de soluções apaixonado por linhas de códigos e por problemas não convencionais

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams