Pair Programming vs. Code Review

Uma das grandes brigas do momento entre FDD e XP seria sobre qual a melhor maneira de trabalhar em conjunto, os XPers sempre fizeram Pair Programming [PP daqui pra frente] e alegam que o processo de Code Review [CR daqui pra frente] já é algo intrínsico ao processo, já coberto pelas práticas como TDD e pelo próprio PP.

Existe uma diferença básica entre as duas formas, enquanto o PP trabalha com código em edição, a CR trabalha com código já pronto. Um é durante, o outro depois.

Como eu sou XPer, você deve pensar que vou escolher PP em detrimento a CR. Você está certo e errado.

PP é muito importante em um processo de desenvolvimento mas não é perfeito – como tudo nessa vida, existem sim GAPs encontrados em códigos, até porque não existiria Refactoring se não houvesse, isso é natural e esperado.

Uma prática bacana em um dos meus clientes [adoro escrever assim, parece que tenho vários clientes] foi a adoção de revisão de código entre a “troca de pares” [Moving People Around, uma prática do XP]. Isso já era natural mas na forma de uma espécie de Standup Meeting [prática do XP] com Brainstorm e dificilmente descia até o código, fizemos algo melhor:

Durante a troca dos pares, fizemos com que o navegador fosse trocado pelo condutor do mesmo par onde ele iria e revisariam o código do período anterior como prática institucionalizada. Os caras trocados revisariam o código anterior e discutiam entre os 4.

Dessa forma a oxigenação com uma nova mente [a terceira nesse caso] no mesmo código gerado consegue um ganho excepcional na cobertura dos testes, já pegamos várias coisas que passariam [principalmente em testes de integração] e evitamos voltar tarefa já concluída para refactoring.

Enfim, são eXperiências e nada de eXcepcional. Eu não tenho compromisso em agradar um ou outro, apenas a meu cliente e a única coisa que ele quer é software funcionando e saudável, para isso precisamos sempre evoluir as práticas adotadas.

6 thoughts on “Pair Programming vs. Code Review

  1. Bruno Pereira

    Oi Milfont, você tocou num assunto interessante, sobre o qual eu já refleti um bocado.

    Os defensores de TDD pregam a escrita dos testes unitários antes da implementação das funcionalidades de negócio. Teoricamente isso traz mais qualidade ao software.

    Eu discordo desta alegação. Eu já desenvolvi muito software customizado, e milhares de testes unitários. Eu me sinto bastante seguro quanto à qualidade dos meus testes unitários, e quanto à cobertura dos mesmos sobre o código que desenvolvo.

    Já tentei algumas vezes escrever os testes unitários no começo, mas simplesmente prefiro a abordagem de escrever os testes posteriormente, preferencialmente acompanhando o desenvolvimento das funcionalidades de negócio. Não vou dizer que estou certo ou errado, considero isso uma questão de gosto pessoal, e de avaliar o que te traz melhores resultados. Provavelmente muitos adeptos de TDD têm ganhos de qualidade ao usar essa abordagem, mas não vejo isso como um dogma a ser seguido.

    Por outro lado, a questão do code review me parece muito subestimada. Eu acho o code review muito valioso quando você está trabalhando com coisas não tão triviais. Entretanto, revisões de código tomam um bom tempo, então não dá para fazer isso o tempo todo.

    Quando eu ainda estava na Globo.com nós usamos uma abordagem que me agradou bastante. Tínhamos tarefas de desenvolvimento de funcionalidades e tarefas de testes unitários. Quando adotamos a regra de um desenvolvedor escrever os testes unitários de funcionalidades implementadas por outro desenvolvedor, com certeza ganhamos em qualidade. Este tempo dedicado à escrita dos testes unitários era aproveitado como revisão de código. O refactoring do código começava mais cedo e antecipávamos muitos problemas que possivelmente não seriam percebidos rapidamente pelo desenvolvedor original.

    Pois bem, no final das contas a minha opinião é semelhante à sua. Devemos conhecer o que nos traz bons resultados e então aplicar essas idéias/práticas. O cliente final não quer saber das siglas que você aplicou no seu desenvolvimento, e nem quer saber detalhes das suas metodologias. Ele quer ser bem servido e ter qualidade. Cabe a nós julgar o que melhor funciona conosco e então fazer uso destes recursos.

    []s

  2. Pingback: Nungo

  3. Pingback: Recomendação sobre TDD - CMilfont Tech

  4. Washington Botelho

    Gostei bastante da idéia de troca de par para review aproveitando para trocar o browser. Com certeza irá cobrir melhor os testes.

    Concordo com o Bruno Pereira no que diz respeito a ter tempo para fazer isso, mas se sobrar um tempinho na Sprint é uma ótima opção, ou até mesmo tirar uma história de vez em quando para a mesma em vez do próprio PP.

    Muito bom o post, parabéns! (:

  5. Pingback: Palestra Agilidade no Mundo Real - Milfont Consulting

  6. Hudson Leite

    Nem tanto Bruno. De uma olhada em [http://www.growing-object-oriented-software.com] e verá que cada tipo de teste (aceitação/integração/unitário) tem sua importância e melhor contexto de uso, mas que sozinhos tendem muito mais a se tornarem um amontoado de código inútil/desagregador de valor.

Leave a Reply

Your email address will not be published. Required fields are marked *