Como melhorar a qualidade e a propriedade coletiva do código? Code Review é uma das soluções!
Como melhorar a qualidade e a propriedade coletiva do código? Code Review é uma das soluções!
ra uma vez, em uma terra não tão distante assim, um desenvolvedor em seu habitat natural tomando sua coca-cola e codando como um doido. Seu código é seu orgulho, sua vida, sua maior criação e desenvolvido baseada na sua imagem... ele acha que é perfeito e lindo como sua mãe sempre disse.
A empresa em que ele trabalha acredita que ele é indispensável, pois aquela parte de código, que só ele trabalha, é importante e ninguém sabe mexer tão bem como ele.
A qualidade do código, vista por outros meros mortais, é algo bastante difícil de entender e todo mundo tem medo de por a mão. Sem qualquer tipo de padrão, um processo de build mágico e sem documentação.
Já viu alguma vez uma situação como esta? Será que isso é bom para a empresa? Será que isso é bom para o desenvolvedor?
Até que um dia, este desenvolvedor entra de férias, fica doente ou simplesmente resolve seguir para uma outra empresa mais legal.
O que acontece com aquele código que está um espaguetti enorme que ninguém consegue entender o motivo. Que não compila na máquina de ninguém direito e sem nenhuma documentação?
Bom, em finais felizes... bem, o código é todo reescrito e a vida que segue... Uma grana enorme em produtividade é perdida e valor nenhum entregue aos clientes.
Em casos não tão felizes... clientes são perdidos e (em alguns casos) a empresa fecha. Fim!
Talvez um dos fatores mais importantes que um time deve buscar é a propriedade coletiva de código. O que seria isso?
Propriedade coletiva de código é capacidade de cada integrante do time trabalhar em toda a base de código do projeto no conforto do seu computador, sem dor nem sofrimento.
Claro que alguns vão demorar uma semana para fazer algo que outros, mais experientes, levariam 1 hora. Não tem problema, isso também pode ser melhorado.
O importante é saber que problemas acontecem e todos devem ter o mínimo de capacidade para resolver.
Code Review é a forma mais rápida e indolor de iniciar um ciclo em que seu time terá propriedade coletiva de código. E qualquer ferramenta de controle de versão que se preste permite fazer isso em seus fluxos de trabalho.
Code Review é o processo em que um desenvolvedor faz as alterações no projeto e, antes do mesmo seguir ir para a próxima etapa (ir para controle de qualidade ou produção), é feita uma revisão das alterações por um outro desenvolvedor.
Com as alterações realizadas, revisadas e aprovadas aí sim seguimos para os próximos passos.
Não sabe como fazer o processo de Code Review no seu sistema de controle de versão? Se estiver usando o Git dê uma olhada como funciona GitHub, no GitLab e no BitBucket.
Se você não tem controle de versão ainda. Sugiro mudar isso urgente. Mas vamos seguindo...
Alguns desenvolvedores são bastante orgulhosos e, para eles, fazer um Code Review onde alguém analisa seu código, pergunta quais os motivos de ter feito de uma determinada maneira e sugere algumas mudanças pode ser algo bastante difícil. Estas pessoas não aceitam muito bem críticas em geral.
Principalmente durante o início da implantação de um processo de Code Review é importante identificar rapidamente estes desenvolvedores mais orgulhosos e alinhar com eles de que é um processo natural e que eles não devem ficar ofendidos.
Em alguns casos, pode até ser que algumas pessoas devam deixar a empresa para que este processo dê realmente certo. Lembre-se quem deve ganhar é o time como um todo e não o indivíduo.
Existem duas maneiras de um Code Review ser mal feito:
Neste caso talvez seja uma questão de experiência do indivíduo ou até mesmo reputação de quem tem o código revisado.
Para minimizar problemas relacionados a experiência do time e reduzir discussões intermináveis, é importante definir padrões mínimos para que o código seja aprovado no Code Review (Ex.: Possui Unit Tests na área alterada? Está passando na Integração Continua? O código está legível? A documentação, quando necessário, foi atualizada?)
Neste caso, é preciso alinhar e ver que a atitude não traz ganhos a ninguém e quem recebe este feedback de outra pessoa pode entrar na defensiva imediatamente e gerar discussões intermináveis.
Com este processo rodando corretamente, o time tende a evoluir muito mais rapidamente. Os padrões de código são estabelecidos naturalmente, a qualidade e a manutenabilidade do código sobem de forma bem significativa.
A grande vantagem deste processo é realmente a capacidade de serem identificados problemas e melhorias no código antes mesmo de ele seguir seu rumo, ou seja, ir para produção ou seguir o processo de testes mais pesados.
Além disso, aquele desenvolvedor agora pode tirar férias mais tranquilamente, ser movido para outros projetos e até mesmo ser promovido!
E se ele sair da empresa... tudo bem... Ele fará falta, mas a vida que segue!