Code Review como ferramenta para formação de equipes

Qual o principal objetivo do Code Review? Diminuir a quantidade de bugs do sistema? Muitos acreditam que sim e não deixam de estar certos, porém esta é apenas uma de muitos resultados da aplicação da prática. A diminuição de bugs poderia muito mais se enquadrar na prática do TDD, utilizando como Code Review como suporte para garantir que todo novo código possui um teste correspondente. Pensando dessa forma, antes do review o build deve estar passando no seu servidor de integração contínua e o estilo do seu código já foi verificado. Se tudo já foi verificado automaticamente, não há mais sentido em uma verificação manual, certo? Na verdade, existem diversos outros objetivos com o code review, que a máquina não consegue alcançar.

Seu objetivo é avaliar o que a máquina não consegue.

Seu objetivo como revisor de código é avaliar se a solução proposta cabe na arquitetura completa do projeto, validar se está fácil de entender o que a solução se propõe a fazer, se você assina embaixo da nomenclatura escolhida para classes, métodos e variáveis. Questões como SOLID, DRY ou mesmo questões de segurança não podem ser deixadas de lado e são pontos onde nenhuma ferramenta de build automatizado pode fazer por você. Outro ponto significativo é analisar como estão sendo testados os novos trechos de código. A cobertura em si pode ser garantida pelo build, mas todos sabemos que ter 100% de coverage não significa que estamos realmente testando 100% do código.

A cada trecho de código que você revisa, você entende melhor como aquele trecho se encaixa no todo do projeto, o que te permite fazer do seu código ainda melhor. Afinal, como você pode dizer que seu código é um bom código para aquele projeto se você nunca leu o código que seu colega escreveu? Eu já me vi em situações, quando minha equipe não possuía a cultura do code review, em que trechos diferentes de código resolviam muito bem seus próprios problemas, mas não conversavam muito bem entre si, e o problema que eu precisava resolver, dependia dessas duas soluções. Se um code review tivesse sido feito em ambas as soluções anteriores, provavelmente elas teriam uma arquitetura em comum, pensada no contexto de toda a aplicação, e não apenas de um trecho.

Busque um código mais homogêneo em termos arquiteturais.

Agora, os guias de estilo solucionam parte do problema, certo? Afinal o que se propõem a fazer é tornar todo o código homogêneo, sem peculiaridades dos mais diversos programadores que passaram pelo projeto. Tabs ou espaços? Comprimento de linha? Tudo padronizado, o build garante isso. Essa já é uma grande evolução e permite uma leitura muito mais fácil de todo o código. Mas homogeneidade vai além da aparência ou estilo. Uma base de código mantida por diversos indivíduos que possuem diferentes experiências tende a ser heterogêneo em termos arquiteturais ou estruturais, usando padrões diferentes em locais diferentes, não de acordo com o que é melhor para a solução, e sim de acordo com sua familiaridade e conhecimento.

Sua contribuição como indivíduo é importante, pois coloca sua experiencia única em ação para construir algo, porém ela é mais importante se for realizada como parte de um todo, e não como uma junção de partes ou contribuições individuais. O processo de Code Review não é um processo de exteriorizar criticas e julgamentos às contribuições alheias, mas de reavaliar sua própria experiência, de aprender com o trabalho dos outros, de descobrir novas formas de se arquitetar soluções.

Para construir um time, é preciso aprendizado compartilhado.

Quando aprendemos levamos mais que apenas conhecimento. Levamos uma parte da experiência do outro, do seu próprio jeito e visão de mundo. No momento em que uma equipe se reúne para construir um projeto, no ponto zero, existem diversos indivíduos com o desafio de se tornar um time. Cada individuo com sua própria experiência. Para de fato se tornar um time, estes individuos precisam ensinar e aprender uns com os outros, para que dessa forma ajam de forma mais semelhante uns aos outros.

Embora o instrumento do code review seja a avaliação do esforço alheio, seu objetivo vai além de uma simples crítica, sendo uma ferramenta para construção de um time.

É possível ver que em um primeiro code review, diversos comentários são realizados, procura-se entender o que foi feito, o porque, como foi pensado. Conforme o projeto evolui, e o status de time também, os code reviews vão sendo realizados com mais facilidade, em menos tempo. O revisor passa a esperar o que esta por vir.

Princípio para uma boa cultura de code review: Honestidade e Transparência

Uma atitude comum em um code review como revisor é não comentar um ponto por medo de ser muito critico, ou receio de que isso possa causar desconforto. É preciso entender que toda vez que isso acontece, você está privando seu time de informação a seu respeito, a como você pensa. Um dos princípios para uma boa cultura de code review é a honestidade e transparência. Seu time precisa te conhecer e precisa estar aberto a uma critica sincera, sabendo que o que está sendo avaliado é o código, e não o programador.

Code review é sobre criar ligações, sobre saber e fazer saber como pensamos, agimos e criamos. Como revisor, seu papel é analisar de acordo com seus próprios conceitos e colocar a sua própria experiência na mesa, para que seu time possa fazer uso dela. Como desenvolvedor que está tendo seu código analisado, seu objetivo é aprender novas formas de fazer o seu trabalho.

Saber comunicar e lidar com as emoções dos outros é essencial.

Algo importante a notar: Embora profissionais, somos antes seres emotivos e é preciso saber lidar com o lado humano das pessoas. Esse é um dos principais motivos pelos quais programadores detestam ter seus códigos revisados. Embora grande parte tenha orgulho e ego envolvido, a maioria simplesmente acredita que fez o melhor que podia fazer, e normalmente realmente o fez. O processo de revisão é algo poderoso, que desperta idéias impossíveis de termos sozinhos. Como revisor, as idéias que você tem não são inteiramente suas, e sim produto das idéias do código original que te serviu de inspiração. Assim que você perceber isso, será mais fácil criticar com humildade e reconhecer o trabalho alheio.

Um primeiro passo para melhorar é aprender a elogiar, não apenas criticar. Isso não é algo apenas para suavizar as criticas que se seguem, mas sim tão importante quanto a própria crítica. Se você viu algo que também faria, diga porque você usaria a mesma solução que seu colega, porque você entende que o que ele fez é um bom trabalho. As vezes ele fez o certo por razões erradas, e isso também o ajudará a continuar seguindo o caminho certo, porem agora pelas razões certas.

Abra espaço para o diálogo usando perguntas ao invés de asserções.

O mesmo vale para o jeito de criticar algo que você pensa existir um melhor meio de fazer. Devo admitir que não sou o melhor exemplo em como lidar com as pessoas. Meu senso de praticidade acaba me tornando direto e seco nas críticas com a intenção de me fazer entender rapidamente, porém o atrito resultante pode acabar gerando o efeito contrário ao desejado. Em um primeiro momento, busque abrandar as palavras e usar perguntas no lugar de asserções. “O que você acha de extrair este método para esta outra classe para diminuir a complexidade?” é muito melhor que “você deveria extrair este método para a classe X”. Conforme seu time amadurece, uma forma única de comunicação entre vocês vai emergir naturalmente, o que tornará os diálogos mais simples.

Se você é lider de uma equipe em formação, não tente evitar que seu time discuta a respeito de suas idéias achando que estão perdendo muito tempo discutindo e pouco tempo trabalhando. Esse é o momento onde (embora uns aparentemente rejeitem as ideias dos outros) seu time está criando laços e se formando. É a troca de conhecimento e de experiência que forma um time, e não a presença física comum e uma mesma sala.

Aprenda a construir novas opiniões quando surgirem divergências.

Finalmente, um ponto importante é que precisamos discutir, mas não podemos discutir eternamente. Naturalmente todos achamos que o que acreditamos é a verdade e corremos atrás de colocar isso em prática, porém todos tem sua própria experiência que deve ser respeitada. Se você está analisando um código que funciona, mas não foi feito do seu jeito, lembre-se da regra da honestidade e transparência e discuta a respeito, mas de espaço para que as idéias se transformem e, talvez ambos encontrem uma nova solução, fruto da experiência conjunta. Quando estamos tentando formar um time, o objetivo é convergir em um mesmo caminho, e não tornarmos todos iguais.

Embora eu não goste muito de ter minha solução criticada, quando eu tenho meu código revisado eu normalmente percebo coisas que não perceberia sozinho. Quando eu crio algo sozinho, vejo um estilo de código meu, minhas soluções, mas não a melhor solução. Quando trabalho em equipe, vejo emergir uma solução muito superior a minha ou a de qualquer um dos meus colegas. Essa sinergia é a minha motivação para trabalhar em equipe.

Na RailsConf desse ano, Derek Prior da Thoughtbot falou sobre como construir uma cultura forte de Code Review e algumas práticas interessantes. Se meu texto te ajudou a se convencer que code review é importante, talvez este vídeo te ajude a entender como pratica-lo na sua equipe.