Em um ambiente de desenvolvimento de software, é preciso adotar rotinas que colaboram para o melhor resultado da equipe como um todo. Não são raras as vezes em que as aplicações são feitas sem o devido cuidado com a parte de revisão. Consequentemente, os códigos tendem a seguir para outras etapas do desenvolvimento sem a correta vistoria sobre a existência de bugs e falhas.
Para mitigar esse problema, preparamos este conteúdo. Você vai entender o que é code review, qual a importância de usar essa técnica no ambiente de desenvolvimento e quais os passos essenciais para aplicá-la de forma eficiente. Continue lendo e fique por dentro do assunto!
O que é code review?
Em poucas palavras, consiste na prática de fazer revisões no código de determinada aplicação. Normalmente, essa revisão é feita a cada commit, que é o nome dado às alterações no software. Outra característica do code review é que, para fazer os ajustes, geralmente, é chamado um desenvolvedor diferente do que está criando os códigos.
Em um commit, o revisor deve analisar arquivo por arquivo, para identificar falhas, bugs e pontos de melhoria da aplicação. Além disso, o code review aplicado a cada commit, normalmente, não leva quinze minutos. Contudo, esse tempo pode ser ajustado, caso seja longo, por meio da diminuição da frequência de envio de um commit.
Como funciona?
Inicialmente, o desenvolvedor do código cria um Pull Request, que pode ser feito em repositórios como o GitHub. A ideia é incluir as mudanças propostas no código, com uma descrição das instruções contidas ali.
Notificando os revisores
Os revisores podem ser designados pelo autor do código. Uma vez notificados pelo Pull Request, eles passam a examinar o código, verificando aspectos como:
- correção — se o código funciona como esperado, resolvendo o problema ou implementando a funcionalidade descrita;
- qualidade — se o código segue os padrões de codificação da equipe ou organização;
- legibilidade — se o código é fácil de entender e manter;
- segurança — se há vulnerabilidades ou práticas inadequadas.
Por que é tão importante aplicar o code review?
Quando um cliente solicita a construção de um software, ele deseja receber um produto que atenda às suas necessidades. Por meio do code review, as falhas e os bugs do sistema são corrigidos a tempo. Dessa forma, a aplicação chegará à etapa de produção e ao usuário final sem nenhuma inconsistência.
No entanto, quem mais se beneficia disso é a equipe de desenvolvimento. Afinal, todos os envolvidos têm as suas habilidades técnicas aprimoradas. Além disso, a prática de revisar código gera um maior nível de cooperação entre esses colaboradores.
Todo esse intercâmbio de conhecimentos também contribui para que a equipe crie soluções alternativas, caso venha a enfrentar algum problema no desenvolvimento. Por conta de prazos ou de falta de conhecimento sobre os recursos da linguagem de programação usada, é comum que o código não fique bem desenvolvido logo de primeira.
Quais os benefícios do code review?
Nenhum cliente quer bugs no seu sistema. Logo, o code review preza justamente a qualidade do código, bem como sua estrutura. Outro benefício importante da revisão é facilitar o fluxo de conhecimento entre os membros da equipe, de modo que melhorias contínuas sejam implementadas.
Mentoria e aprendizado
Em uma equipe, é comum haver tanto desenvolvedores experientes quanto iniciantes. Dito isso, o code review é uma excelente maneira de aumentar a bagagem de quem está trabalhando há pouco tempo na área.
Pessoas nessa situação estão bastante propensas a aprender, e isso acaba sendo benéfico também para os clientes. Afinal, estes podem ter a certeza de que sua aplicação está nas mãos de uma equipe realmente qualificada.
Redução do débito técnico
Sem a revisão de código, há uma tendência para os problemas se acumularem ao longo do tempo. Quando isso ocorre, os custos de reparação também costumam ser maiores. Portanto, aplicar o code review também é um modo eficiente de eliminar custos e entregar a solução do cliente dentro do prazo, seguindo todos os requisitos do projeto e as boas práticas.
Documentação
Os comentários e as discussões em torno do código fornecem uma forma de documentação que pode ser útil para futuros desenvolvedores. Sem isso, quem chegar futuramente à equipe pode ter grandes dificuldades de entender e manter o código, uma vez que não tem comentários, ou estes foram feitos apenas verbalmente, por exemplo.
Quais as melhores práticas?
Vamos iniciar o tópico falando de padrões de codificação e ferramentas automatizadas. Sobre o primeiro, é de suma importância que a equipe trabalhe com guias de estilo, além de meios que permitam verificar a conformidade com esses padrões.
Prefira revisões de código menores e mais frequentes, pois são mais fáceis de analisar e menos propensas a erros. O ideal é que cada revisão foque uma única funcionalidade ou bug.
Outras práticas gerais que merecem destaque são:
- limitar o tempo de cada sessão de revisão para cerca de 60 minutos, tendo em vista que revisões longas podem levar a uma queda na atenção e na qualidade da análise;
- dar feedback claro, específico e construtivo, evitando críticas pessoais e focando as melhorias do código;
- usar os comentários para explicar o raciocínio por trás das sugestões;
- avaliar o design e a arquitetura do código, garantindo que ele seja escalável e fácil de manter;
- verificar a cobertura de testes, incentivando a escrita de testes automatizados.
Como aplicar o code review de maneira eficiente?
Para usar o code review da forma correta, é necessário adotar uma série de boas práticas, tais como:
- usar uma wiki, que é um documento formado por todas as atividades relacionadas ao projeto;
- usar checklists;
- estar atento às novas ameaças, para a segurança da aplicação;
- usar a automação em conjunto com o trabalho manual, no intuito de identificar padrões e falhas recorrentes;
- usar ferramentas para otimizar o processo, como o Android Lint, o Findbugs e o Checkstyle.
Saber o que é code review ajuda bastante as equipes de desenvolvimento de software. Uma vez que a revisão é feita constantemente, as falhas e os bugs são identificados a fim de aprimorar ainda mais o sistema e satisfazer o cliente. Além disso, os colaboradores passam a compartilhar conhecimentos, o que contribui para o aperfeiçoamento de suas habilidades técnicas.
O que achou deste conteúdo? Não saia do nosso blog sem antes conferir tudo sobre a nova legislação de proteção de dados.
Foi aluno de Ralph Kimball, maior referência mundial no assunto, no curso de Modelagem Dimensional realizado pela Kimball University, em Estocolmo – Suécia.
Já ministrou diversas palestras sobre o tema e atualmente mantêm o blog da Know Solutions, com referências sobre Business Intelligence.
Pós Graduado em Gestão de Projetos de Software pela PUC – Paraná. Trabalhou durante 7 anos na empresa Siemens onde participou de projetos em diferentes países.
Materia muito interessante
Obrigada pelo artigo 🙂 Acho que eu tenho uma equipe que pode obter cada sucesso 🙂 Mas sem kanbantool.com, nao conseguimos arranjar e controlar todas tarefas. Ferramentas digitais podem ajudar bastante – tal como manager ou teamledaer, mas mais suave 🙂 Eu planejo o dia do trabalho com kanban e todas tarefas sao cumpridas. Eu sei que nao cada um gosta trabalhar assim, mas comigo funciona 🙂
Parabéns por trazer a CRISP-DM de volta ao tablado. O “produtocentrismo” que assola o mercardo de BI pressiona os players a comprar o último brinquedo, a seguir a última moda, quando quase tudo que tem algum uso prático já existe há décadas – como o CRISP-DM
Seria legal um artigo um artigo comparando-o com SEMMA. Pode ser muito interessante para quem entrou na área há menos de 20 anos.
Gostaria de entender se a utilização da Big data nas empresas gera algum tipo de desvantagem nas pessoas que lá trabalham ?
Sobre o comentário do João Kechichian, concordo em relação às empresas não terem claro o que querem, e concordo com o Leandro sobre a abordagem de “Qual o seu problema” para dar as sugestões.
Mas vale ressaltar que as empresas não conseguem identificar o que querem por não terem claro um Planejamento Estratégico e objetivos bem descritos. Isso facilita muito perceber quais indicadores serão necessários acompanhar para atingir os resultados esperados.
Bom dia,
Há muita diferença das versões do livro The Data Warehouse Toolkit?
Vejo que ele esta na 3 edição.
Posso comprar apenas a 3 ou devo comprar todas?
Oi Marcos!
Há algumas atualizações com conceitos mais atuais. Não precisa comprar todas as edições não, apenas a 3a já cobre tudo que precisa.
Sim e não. A maior diferença é entre a primeira edição e as restantes. Da segunda edição em diante, quando a Margy Ross assumiu o livro, é tudo mais ou menos o mesmo.
A primeira edição, que por acaso chegou a ser publicada em português, é a melhor, na minha opinião. Ela é mais concreta, menor e mais focada. Se conseguir achá-la, compre. Vale ouro.
eu precisava para compor você uma pouco de note ajudar diga obrigado again com o extraordinário conselhos você compartilhado nesta página . Foi certamente maravilhosamente generoso com você dando abertamente tudo o que muitas pessoas {poderiam ter | poderiam possivelmente ter | poderiam ter | teriam | distribuído para um ebook para gerar alguma massa para eles mesmos , especialmente considerando que you poderia ter tried it se você nunca desejado . Those estratégias também agido como outras pessoas tenha semelhante desire como my own entender bom negócio mais relacionado este assunto . Eu tenho certeza há alguns mais agradáveis ocasiões ahead para pessoas que ver seu site
[…] de BI — Business Intelligence ou, traduzindo, Inteligência Empresarial — é justamente o diferencial que uma empresa precisa para tratar dados gerados por vários meios. Veja alguns contextos que podem servir de […]
[…] para aumentar seu lucro ou diminuir seus custos operacionais. Esse é o conceito básico de Business Intelligence utilizado como diferencial […]
Olá Leandro.
Acredito que o potencial da área de Business Intelligence dentro das empresas pode ser maior do que se imagina hoje.
Trabalho com consultoria de B.I. para agencias e empresas, e enfrentamos diariamente dois grandes problemas.
1- Padronização dos dados: Como utilizamos muitas fontes de dados, todo o processo, desde o que a implementação, até a parte operacional, precisa ser muito bem estruturada. Sem o padrão das informações perde-se muito tempo com “correção”, sendo que “tempo” não é o que temos para identificar um padrão, pois no dia seguinte ele pode mudar se não o tratarmos.
2- Pessoas que não sabem o que querem: Corporações não sabem o que querem, logo querem tudo. O problema é que sabemos que não tudo não é necessário, se consegue identificar padrões e otimizações com metade do volume. Sendo assim o processo de otimização passa a ser inteligente para ser operacional.
O futuro da área esta encaminhando para segmentações e clusterizações dinâmicas para analise de Big Data, mas se o processo de todos envolvidos precisa ser muito bem desenhado e a área de B.I. precisa ter este knowhow também.
Obrigado e muito bom seus artigos.
Oi João, obrigado pelo seu comentário! Concordo com você!
Realmente, a padronização dos dados é o ponto mais sensível mesmo. Aqui estimamos em torno de 60% a 70% do tempo em um projeto de BI apenas para esta parte.
Sobre as pessoas não saberem o que querem, aqui vemos como uma certa vantagem. Muitas vezes não é nem exatamente não saber o que querem, mas não saberem o que é possível fazer. Com isso, parte do nosso trabalho aqui é exatamente entender do que o cliente sofre aí então sugerir algumas coisas. Tentamos não ir para uma abordagem de “o que você quer” mas sim de “quais são seus problemas”.
Isso me deu até a ideia de criar um post focado nisso, vou deixar anotado para o futuro!
Existe uma técnica chamada Árvore de Realidade Presente, da Teoria das Restrições, que lida justamente com essa barafunda de problemas e entendimentos. Eu experimentei a mesma frustração que você, João, e decidi resolver esse problema. A imagem https://geekbi.files.wordpress.com/2020/10/bi_toc-crt-x.png é um resumo do que eu tenho até agora.
Adoraria uma contribuição. “O cliente não sabe o que quer” já está lá. “Dados são sujos” e “Dados são bagunçados” me parecem boas adições.
O que você acha? E você, Leandro?