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.
Typically chemist’s shop can sale to you with discreet treatments for various soundness problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a extremely complicated question. Matters, like “coupons for viagra“, are coupled numerous types of heartiness problems. If you need to take prescription medications, ask your dispenser to check your testosterone levels before. Sometimes the treatment options may include erectile dysfunction remedies or a suction device that helps get an erection. Keep in mind web-site which is ready to sell erectile dysfunction drugs like Viagra without a formula is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.
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
Pingback: Nungo
Pingback: Recomendação sobre TDD - CMilfont Tech
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! (:
Pingback: Palestra Agilidade no Mundo Real - Milfont Consulting
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.