Como melhorar a qualidade e a propriedade coletiva do código? Code Review é uma das soluções!

Os problemas que a falta de propriedade coletiva de código traz

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?

Quando o conto de fadas pode não ter um final feliz

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!

Propriedade coletiva de código

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.

Eis que entra o Code Review

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...

Quando o dono do código não aceita o Code Review

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.

Quando o Code Review não é bem feito

Existem duas maneiras de um Code Review ser mal feito:

Quando a pessoa não analisa efetivamente o código, não questiona e não olha minimamente os padrões estabelecidos pelo próprio time

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?)

Quando quem está fazendo o Code Review é arrogante e trata o criador do código como alguém que fez uma grande cagada e não merece qualquer respeito

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.

Quando o Code Review é bem feito

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!