Pair Programming vs. Code Review

{ February 3rd, 2009 }


cmilfont

Autor: cmilfont

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.

Categories: Engenharia de Software, Melhores pr√°ticas, Metodologia, M√©todos √Āgeis, Scrum, Test Driven, XP ~ ~ Trackback


Assine os coment√°rios deste artigo.


6 Responses to “Pair Programming vs. Code Review”

  1. 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. 2
    Nungo

    Pair Programming vs Code Reviewling√ľi√ßa…

    Seu cora√ß√£o, digo, artigo foi citado no Nungo: http://nungo.com.br/programacao/pair-programming-vs-code-review/ #…

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

    […] Bruno Pereira comentou em post passado sobre a dificuldade que ele teve em adotar TDD: “J√° tentei algumas vezes escrever os testes […]

  4. 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. 5
    Palestra Agilidade no Mundo Real - Milfont Consulting

    […] Trabalho energizado Pair Programming http://www.milfont.org/tech/2010/06/17/trabalho-energizado-e-a-teoria-das-2-horas-produtivas/ http://www.milfont.org/tech/2009/02/03/pair-programming-vs-code-review/ […]

  6. 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