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
OPML Completo.
Texto Completo
February 4th, 2009 at 7:17 pm
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
March 16th, 2009 at 7:57 pm
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/ #…
June 1st, 2009 at 4:05 am
[...] Bruno Pereira comentou em post passado sobre a dificuldade que ele teve em adotar TDD: “Já tentei algumas vezes escrever os testes [...]
March 15th, 2010 at 6:27 am
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! (:
July 12th, 2010 at 6:17 am
[...] 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/ [...]
May 17th, 2011 at 7:56 pm
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.