Entregue mais rápido e com mais qualidade aplicando revisões de código
Programação não é uma atividade simples.
Há quem diga que aprender uma linguagem de programação é como aprender um idioma. Há também os que acham que programar é como resolver problemas de matemática. Mas estudos mostram que a leitura de código fonte ativa uma área do cérebro chamada de rede de demanda múltipla. Essa rede é responsável por praticamente tudo que é cognitivamente desafiador onde precisamos manter muitas informações em mente ao mesmo tempo. O estudo desbanca ambas teorias, o que nos faz pensar que programar acaba sendo uma espécie de união das duas.
Bom, se programar é uma atividade desafiadora, qual o melhor jeito de evoluir na programação?
PRÁTICA.
E prática envolve ler e escrever código. Escrever código é uma arte. É como escrever um livro, um artigo ou falar sobre algum acontecimento. Precisa ter uma linha de raciocínio e você pode pedir à várias pessoas para contarem a mesma história e cada uma vai contar de uma maneira diferente. Umas terão uma habilidade especial em fazer isso e outras nem tanto. Mas, normalmente, você percebe que as que contam melhor, já escutaram e já contaram mais histórias que as outras.
Quando lemos código de outra pessoa, aprendemos maneiras diferentes de resolver um mesmo problema. Incorporamos o aprendizado e até conseguimos, com o tempo, opinar melhorias nos códigos que lemos.
O código que eu escrevo hoje, é melhor do que o código que escrevi ontem. E acho que isso todos que desenvolvem concordam, pegue um código antigo seu e você verá que reescreveria ele de outra maneira. Você evolui suas próprias técnicas diariamente.
E sabe porque é difícil também programar? Precisamos escrever código que não somente a máquina entenda e execute, mas código que outras pessoas entendam e possam alterar futuramente. Você escreve código, inclusive, para o seu eu do futuro! Já pensou nisso?
Eu aprendi MUITO lendo códigos em repositórios abertos e em livros. Quando comecei estudar padrões de projeto, nem sempre eu entendia totalmente os códigos. Mas, com o tempo, tudo começava a fazer sentido. As peças iam sem encaixando.
Mas tem um lugar que poucos percebem que podem aprender lendo códigos dos outros todos os dias. Sabe onde? No seu trabalho! Todos os dias! E a ferramenta de chama PULL REQUEST.
Tem gente que acha chato ficar revisando código dos outros e acha que ter que ficar procurando erro em código é perda de tempo. Mas é porque estão olhando pelo lado errado.
O pull request é uma das ferramentas de comunicação mais importantes de um desenvolvedor.
Vamos tentar olhar de uma perspectiva diferente. Segue o fio.
Com ele você lê código dos outros e os outros leem seu código.
Ok. Mas você também:
- lê e aprende maneiras diferentes de escrever código;
- sugere e ensina as suas melhores práticas pros outros;
- se força a escrever o seu melhor código pros outros e ainda;
- recebe sugestões e aprende com as boas práticas dos outros desenvolvedores.
Olha quanta troca!
Já pensou que você pode ver a solução daquela feature que você gostaria de ter feito, analisar o código e contribuir? Já pensou que você pode ver um código não tão bonito de um programador mais Sênior e entender o porquê ele fez daquele jeito?
A revisão de código permite que a equipe:
- fique atenta e garanta o design da aplicação;
- garanta as convenções de código definidos pela equipe;
- aponte e seja apontada nos bugs mais simples ou em regras que afetam uma parte da aplicação não tão óbvia;
- e por ai vai…
É verdade também que há boas práticas nessa técnica e se tem uma coisa que escuto diariamente e concordo é que é muito ruim realizar uma revisão de código de um pull request gigante com vários arquivos e diversas linhas alteradas.
Como eu posso saber por onde eu começo? Qual a linha de raciocínio que o autor seguiu para chegar naquela solução?
Faça revisões de código mais rápidas, fáceis e efetivas
Estudos mostram que 400 linhas de códigos é o limite superior de tamanho que garante uma revisão de código efetiva. Revisões de código maiores que esse tendem a perder qualidade por parte dos revisores.
Uma solução simples que podemos pensar para tentar seguir o raciocínio do autor é seguir o histórico de commits que ele realizou. Desta forma podemos revisar pequenos trechos de código e ir validando o raciocínio acompanhando o processo e o trabalho do autor.
Mas esse processo que o autor segue pode ser confuso, pois ele vai organizando os pensamentos conforme vai avançando. E para quem está revisando pode ser bem difícil de entender a conclusão do trabalho.
Para facilitar podemos aplicar uma técnica chamada STACKED PULL REQUESTS.
STACKED PULL REQUESTS
A técnica é simples e consiste basicamente em você separar o seu trabalho em vários pull requests pequenos que mostrem uma linha de raciocínio para os revisores. Você precisa APRESENTAR seu trabalho. Esta linha de raciocínio, pode inclusive ser definida em equipe pensando nas camadas do sistema, por exemplo. Isso vai agilizar e aumentar a produtividade e qualidade do processo inteiro.
Na prática você irá criar uma feature branch para desenvolver a funcionalidade. E a cada sequência lógica de código você irá criar outra branch a partir desta branch que você havia criado.
Deve ficar claro para a equipe que aquele pull request é um trabalho em progresso. Isso é importante para que ele não seja aceito e integrado até que todos os pull requests da funcionalidade estejam preparados para revisão.
Os revisores podem assim olhar o código de cada branch e aprovar ou fazer suas considerações. Após o autor conseguir aprovação de todos pull requests ele deve incorporar as branches de maneira inversa à criação.
Então na prática, a partir de uma branch develop você irá seguir desta maneira:
- criar uma branch WIP#01 (Work in Progress) baseada na develop;
- criar uma branch WIP#02 baseada na WIP#01;
- criar uma branch WIP#nn baseada na WIP#nn-1;
A sequência de abertura de pull requests deve seguir:
- pull request da WIP#01 para develop;
- pull request da WIP#02 para WIP#01;
- pull request da WIP#nn para a WIP#nn-1;
A sequência de aprovação dos pull requests deve seguir de maneira inversa a abertura:
- completar pull request da branch WIP#nn para WIP#nn-1;
- completar pull request da branch WIP#02 para a WIP#01;
- completar pull request da branch WIP#01 para develop.
CONVENCIONE E ENTREGUE MAIS RÁPIDO
Quanto mais alinhado o time estiver quanto as convenções e estilo de programação, mais velocidade você ganha no desenvolvimento, pois possibilita aumentar a paralelização do desenvolvimento. Até mesmo de uma mesma feature, inclusive. Enquanto um desenvolvedor atua na camada de banco de dados, outro atua na camada de negócio, por exemplo.
Ouvi uma história certa vez de dois desenvolvedores tão bem alinhados que um fez o HTML e o outro desenvolveu o CSS de uma página web. Os dois trabalharam em paralelo e no final juntaram os trabalhos, fizeram os ajustes e entregaram uma funcionalidade urgente muito mais rápido que um desenvolvedor só poderia fazer.
Entendo que é um nível de alinhamento e conhecimento de time realmente alto, e que alcançar isso passa por boas revisões de código.
E você? Já curtia fazer revisão de código?
Se não curtia, espero ter feito você pensar um pouco sobre o assunto.
