A arte da revisão

Não estaria a exagerar se dissesse que passamos pelo menos uma hora por dia a rever o trabalho uns dos outros. Porquê tanto? A resposta é clara. Através da revisão pelos pares, mantemos a qualidade dos nossos produtos. Para além disso, aprendemos muito com isso enquanto receptores e revisores de feedback. Mas concluir uma revisão não é tarefa fácil. É necessário criticar de forma construtiva o trabalho dos seus colegas, alguns dos quais com sangue, suor e lágrimas. Como tornar o feedback construtivo e claro? Discutimos três métodos de revisão por pares, incluindo o nosso favorito.

Soluções, soluções, soluções 

Para otimizar a qualidade do seu trabalho, é necessário um feedback profundo. Uma forma de fazer a revisão por pares é o que eu chamo de método do sabe-tudo. O código ou texto é seu. Já viu todas as palavras, todas as frases, todas as interfunções ou todas as cadeias de caracteres várias vezes e sugere alternativas para as partes que não cumprem as normas de qualidade. Por vezes, isto é acompanhado de uma explicação sobre o motivo da alteração;

No passado, utilizei este método. Veja como alterei a introdução que o meu colega Jeroen escreveu para o seu artigo "Why we don't do overtime";

Reconhece isto: está num projeto com um prazo apertado. Está a fazer horas extra para cumprir o prazo. Após alguns dias de horas extraordinárias, chega a casa tarde e cansado, come de forma pouco saudável e vai diretamente para a cama. Na manhã seguinte, levanta-se cedo, ainda sem ter recuperado da noite curta. Recomponha-se... Seja forte e heroico e cumpra este prazo. Promete a si próprio que da próxima vez será diferente. Que vai planear melhor, fazer as melhorias que não fez desta vez. Sairás do escritório a horas e irás comer com a tua família ou tomar uma bebida com os teus amigos. Só que da próxima vez há outro projeto importante com um prazo a cumprir. E repete-se.

_{Projeto de introdução do artigo "Porque não fazemos horas extraordinárias", escrito por Jeroen.}

Sugeri que o mudasse para isto, para o tornar mais apelativo como introdução:

Na maioria dos empregos, as horas extraordinárias são frequentemente esperadas. Não acreditamos que as horas extraordinárias sejam a solução para realizar o trabalho e cumprir os prazos. Sempre e sempre. De facto, pensamos que são contraproducentes. É por isso que terminamos o trabalho após um dia de oito horas, um dia normal de trabalho nos Países Baixos.

_{Introdução final do artigo "Porque é que não fazemos horas extraordinárias", escrito por Jeroen.} 

Na minha opinião, a introdução de Jeroen era demasiado longa e consistia em informações que se repetiam no corpo do texto. Gastei algum tempo a elaborar uma nova introdução e o Jeroen aceitou-a;

Substituir o seu próprio trabalho pelo trabalho de outras pessoas reduz o sentimento de propriedade total.

O que é que correu mal? Dei imediatamente a solução. Este método de revisão não é melhor do que simplesmente pedir aprovação. É claro que, como recetor do feedback, fica a perceber a razão da alteração. Mas, ao não o reescrever, perde a oportunidade de melhorar as suas capacidades de escrita. Para além disso, substituir o seu próprio trabalho pelo trabalho de outras pessoas reduz o sentimento de propriedade total. O trabalho deixa de ser seu. Além disso, os seus níveis de insegurança podem aumentar, o que pode causar uma pior qualidade do trabalho futuro. O método do saber-tudo também pode facilitar outra coisa completamente diferente: toma-se o feedback como garantido e deixa-se de o criticar. Isto é algo que também não queremos, porque cada ponto de feedback deve ser também uma oportunidade de aprendizagem. Na nossa opinião, analisar o feedback recebido é fundamental para o seu próprio desenvolvimento como programador (front-end ou back-end) ou escritor. 

Rápido e sujo 

No outro extremo do espetro, temos o método rápido e sujo. Este consiste em pedir aos seus pares que aprovem o trabalho que fez para passar à etapa seguinte do processo. Na verdade, não queres feedback. Só quer algo online porque: 

1. Desenvolveram o pedaço de código em conjunto (pair programming). 

2. É uma alteração tão pequena que nada pode correr mal. 

3. Sentes pressão de tempo e os comentários causam um atraso.

4. Discutiste a solução com um colega e implementaste-a depois.

No caso das razões A e B, a forma rápida e suja é permitida. No nosso trabalho quotidiano, fazemo-lo com bastante frequência. Faz parte do nosso processo. Mas isso não vale para as razões C, D e outras tarefas complexas. De facto, é necessário um par de olhos extra, porque o diabo está nos detalhes;

Encontrar-se no meio 

Os dois métodos de avaliação pelos pares mencionados não são ideais em termos de aprendizagem. É por isso que o nosso método preferido se encontra algures no meio. Na nossa opinião, o valioso feedback dos pares:  

• É construtivo. Tratamos os colegas e o seu trabalho com respeito. 

• Faz-nos pensar. Ajuda-o a refletir sobre o seu trabalho e incentiva-o a pensar noutras soluções. 

• Consiste em perguntas. Porque é que fez as coisas desta maneira? Qual é a razão para esta configuração? Pensou na opção X e Y em vez de apenas na Z?

• Possibilita que as pessoas processem o problema elas próprias. Aponta-lhes a direção certa, sem dar a solução completa. No entanto, por vezes é muito difícil conter-se, especialmente quando se trata de pequenos erros. Por exemplo: funções e variáveis nomeadas de forma inconveniente (código) ou erros gramaticais (conteúdo).

Vemos o feedback dos colegas como um início de conversa. Joan, um programador de back-end na Easy LMS, explica:  "Não revelo a solução completa, por vezes apenas uma parte, mas discuto principalmente a forma como uma alternativa pode ser alcançada através da refacção. E isto, por vezes, significa literalmente sentar-me ao lado de alguém para o orientar, em vez de jogar pingue-pongue através do GitHub ou do BitBucket, as ferramentas que utilizamos para revisões de código."

"O que também faço por vezes: Ofereço várias alternativas e deixo que seja o recetor do feedback a decidir qual a alternativa que mais lhe convém. É um desafio para o cérebro, porque várias opções têm de ser cuidadosamente consideradas."

_{Exemplos de uma conversa de revisão de código no GitHub.}

De acordo com Joan, o feedback conversacional nem sempre é necessário. Depende do tipo de código. "Suponhamos que alguém colocou acidentalmente uma vulnerabilidade (de segurança) no código, então é evidente que tem de ser removida. Claro que vou explicar porque é que deve ser removida e como a pode evitar a partir de agora, mas não é o momento ideal para uma grande conversa. Nesse caso, o método saber-tudo é mais adequado".

Anna, a nossa consultora de implementação e falante nativa de inglês, verifica todos os textos em inglês antes de serem colocados online e aplica também o método de conversação . Há apenas algumas semanas, ela própria corrigiu erros gramaticais. Agora, recorre mais frequentemente ao nosso Guia de Estilo, para que as pessoas possam corrigi-los sozinhas.  "E quando alguém está sempre a trocar os tempos verbais, pergunto-lhe qual o tempo verbal que deve ser utilizado."

Demora mais tempo, mas acaba por compensar 

Quanto mais se processa o feedback, melhor se fica e menos tempo é necessário para obter a qualidade correta da próxima vez.

Este último método de avaliação pelos pares exige muito tempo, especialmente no início. Esta é provavelmente uma das razões pelas quais, por vezes, voltamos a cair nos nossos velhos e confortáveis hábitos. Mas dizemos a nós próprios uma e outra vez: quanto mais o feedback nos faz pensar e quanto mais o processamos, melhor ficamos no nosso trabalho. Assim, na próxima vez, demorará menos tempo a apresentar a qualidade correta. Os benefícios são duplos. Em última análise, o revisor também levará menos tempo a rever. Mesmo assim, é importante continuar a ser crítico e a dar feedback valioso, porque isso ajuda:

• Envolver os seus colegas no seu trabalho diário. Não há ilhas isoladas de trabalho. 

• Aumentar a confiança no trabalho que se cria porque alguém acha que vale a pena olhar para ele.

• Melhorar a qualidade do trabalho. É um investimento a longo prazo que evita erros (dispendiosos).

Este artigo foi revisto na forma de conversa?