Git guilt, culpa e revisão do código

Tim Petterson
Tim Petterson
Voltar para a lista

Nos últimos tempos, tenho percorrido a segunda etapa do tour do Getting Git Right. Tem sido incrível conhecer tantos desenvolvedores de todo o mundo. Tem sido particularmente incrível ver o quanto a adoção do Git cresceu entre os participantes nos poucos meses desde a primeira etapa do tour. Na apresentação de julho, quase todos os participantes levantaram a mão quando a gente perguntou "Quem está usando o Git?"

Porém, há um ponto baixo em todas as noites que eu organizei: o momento depois de fazer a pergunta "Quem está fazendo a revisão de código no trabalho?"

Em geral, menos da metade do público levanta a mão.

É algo que me deixa triste, porque a revisão de código tem sido muito valiosa para mim durante minha carreira. Na verdade, eu recomendaria a revisão de código antes de qualquer outra prática ou tecnologia como a maneira mais eficaz de conseguir o aumento incremental da qualidade de qualquer base de código. E a implementação de DVCS (sistema de controle de versão distribuído) da revisão de código (a pull request) é uma ferramenta ainda mais incrível.

Estes são os 3 principais motivos para eu ter essa visão:

Um código melhor

A primeira razão é bastante óbvia: ter desenvolvedores com níveis de experiência diferentes, especializações técnicas diferentes e perspectivas diferentes analisando o código faz com que você tenha uma chance muito maior de detectar bugs e reduzir débito técnico — antes que o código chegue aos clientes. Se você estiver usando pull requests, esses itens vão ser detectados antes mesmo de seu código chegar ao branch principal, então os itens capturados na revisão não vão afetar ninguém. Ou seja: a qualidade da sua base de código e do produto que você está lançando aumenta muito.

Compartilhamento de conhecimento

O segundo motivo é um pouco mais sutil. Os desenvolvedores que estão revisando o código não estão apenas prestando um serviço gratuito sem nenhum benefício para si mesmos — eles também estão aprendendo! Como desenvolvedor júnior, assistir a revisões de código me ensinou mais sobre padrões e bibliotecas de software do que qualquer livro que li ou apresentação de que participei. Como desenvolvedor sênior, as revisões de código revelaram muitos conhecimentos tribais específicos de um projeto ou uma equipe de software específicos. Cada aplicativo tem pilha, padrões e idiossincrasias próprios que moldam a melhor maneira de corrigir um bug ou implementar um recurso. A revisão de código faz um ótimo trabalho ao divulgar essas informações pela equipe.

Propriedade comunitária

O terceiro motivo é o mais esquecido, mas certamente um dos mais importantes para a integridade do produto a longo prazo. Se você é desenvolvedor, já deve ter lançado um bug para um cliente em algum momento. É uma sensação horrível. Você vê o relatório de bug aparecer no Jira durante uma sessão de triagem, você lê a descrição estranhamente familiar com um frio na barriga e percebe que o código que você criou e lançou está causando muitos problemas a um cliente (provavelmente vários clientes).

No entanto (e agora vou contar um segredo), se você está fazendo a revisão de código como parte do processo de desenvolvimento, esse bug não é sua culpa! Pelo menos, não sua. A fórmula para a culpa do desenvolvedor é assim:

g = 1/(n+1)

Se n desenvolvedores aprovaram a revisão, você só sente 1/n+1 de vergonha quando lança um bug.

Eu estou (meio que) brincando. Mas, em termos práticos, se n desenvolvedores aprovaram uma revisão, você tem n desenvolvedores que podem tomar a frente e corrigir o bug se o autor original saiu da empresa/está dormindo em outro fuso horário, seja o que for, enquanto você tem clientes acordadíssimos gritando ao telefone ou no seu rastreador de itens.

Portanto, essas são as três principais razões pelas quais eu acho que a revisão de código é uma boa prática para equipes de qualquer tamanho com mais de uma pessoa. Essa é uma boa introdução para o principal motivo pelo qual estou escrevendo este blog! Recentemente, lancei uma pequena ferramenta para tornar a revisão de código (com o Git) um processo mais fácil.

Uma das partes complicadas da criação de uma pull request é determinar o conjunto perfeito de pessoas para revisar seu código. Às vezes é óbvio. Se você trabalha em uma equipe pequena ou está na mesma equipe há algum tempo, sabe quem é o especialista na área relevante para a parte da base de código que você modificou. Mas se você é novo em uma equipe, trabalha com um grande número de pessoas ou está contribuindo para um projeto fora do seu trabalho regular, a decisão pode ser um pouco mais complicada.

Conheça o git-guilt

O git-guilt é uma pequena ferramenta que escrevi que permite ver a transferência de culpa em um repositório causada por diversos commits. Por exemplo, se você quiser ver como a culpa mudou de um autor para outro durante seu último commit, você pode executar o comando:

git guilt HEAD~1
Terminal — bash — 98×28 2014-07-17 18-17-48 2014-07-17 18-49-07

O resultado indica que no meu último commit eu adicionei 239 linhas de código, ao mesmo tempo em que removi 2 linhas antes atribuídas a Patrick, 5 linhas de Seb, 13 linhas de Anders e um monte de linhas de JD. É divertido se você for competitivo por natureza, mas, em um sentido mais prático, os desenvolvedores que aparecem na saída são bons candidatos para revisar a pull request que vou criar para fazer o merge dessas alterações de volta ao branch principal.

A lógica por trás disso é que os desenvolvedores cujo código você está reescrevendo podem ter algo a dizer sobre o assunto. ;)

O git-guilt é chamado assim porque mostra a transferência de culpa (ou guilt) de uma base de código entre commits. Como outros comandos no pacote do Git, ele pode receber qualquer commit ou ref como argumento. Por exemplo, usando o comando merge-base para determinar o ponto do branch, você pode mostrar a culpa de um branch de recurso inteiro assim:

 git guilt `git merge-base main my-feature-branch` my-feature-branch
Terminal

Ou a alteração da culpa ao longo de um período de tempo:

git guilt `git log --until="3 days ago" --format="%H" -n 1
terminal

Instalação

O git-guilt é empacotado como um módulo npm, então a instalação é fácil se você quiser dar uma olhada:

  • Confirme se você tem o Git, o Node.js e o npm instalados
  • Execute npm install -g git-guilt (você pode precisar de sudo)
  • Execute git-guilt HEAD~1 em qualquer repositório do Git para ver o delta de culpa para o commit mais recente. Outra opção fácil é fazer a instalação como um hook post-commit, para mostrar a transferência em tempo real da culpa do código ao criar novos commits no local. Basta repetir o seguinte para .git/hooks/post-commit:
#!/bin/sh git guilt HEAD~1

e verificar se o arquivo é executável:

chmod a+x .git/hooks/post-commit

Na próxima vez que você fizer o commit, vai ver a saída do git-guilt mostrando como a culpa mudou.

Perfil de correção

A fonte está disponível no Bitbucket se você quiser ler ou contribuir.

É fã do Bitbucket Server?

Se achar essas informações úteis e estiver usando o Bitbucket Server para hospedagem de Git, você pode aproveitar o complemento gratuito Reviewer Suggester for Bitbucket Server que eu criei para uma competição ShipIt há algum tempo. Ele implementa um algoritmo semelhante para sugerir revisores (com alguns enfeites) e está bem integrado na IU de criação de pull request do Bitbucket Server.

P.S.: Estou falando sério

Se você é um dos 50% dos desenvolvedores que leem este material que não estão praticando a revisão de código, comece hoje mesmo. Você não vai se arrepender! Você poderia ter identificado um bug (poupando vários clientes de problemas) e aprendido várias coisas novas sobre sua base de código em menos tempo do que demorou para ler este blog. :)

Pronto(a) para aprender Git?

Tente este tutorial interativo.

Comece agora mesmo