Programação em par defendida pelos números

É muito interessante notar a reação das pessoas quando tentamos introduzir a idéia da programação em par. A primeira reação, normalmente é:

Porque devo colocar duas pessoas para fazer o trabalho de uma?

Este argumento, em primeira vista válido, não passa de uma avaliação superficial do que realmente ocorre em um processo de desenvolvimento. A maioria das pessoas acredita que o processo de desenvolvimento seja, em sua essência, escrever código. Mas, não é. Na verdade, escrever código é a menor parcela neste processo. A maior atividade neste processo é pensar.

Quem já tem alguma vivência no mundo do desenvolvimento, sabe que quando colocamos a mão no código, já temos algo em mente que precisa ser implementado. Não estou me referindo a UML, análise antes de implementar ou waterfall. Antes de escrever qualquer linha de código você deve (ou deveria) saber porque está escrevendo aquilo, isto é, quais são seus objetivos. Antes de escrever essa primeira linha, você já tem uma idéia da lógica que será usada.

Nesse ponto, é possível provar a importância da programção em par, pois é onde temos o maior risco de decisões ruins e inserir erros. Estes erros irão custar tempo de desenvolvimento no futuro. E tempo é dinheiro.

O grande valor da programação em par está na possibilidade de pequenas correções de curso, e eliminação de erros logo assim que eles aparecem. Esses erros podem ser sutis e um overlook do par pode impedir que sigam adiante possibilitando, dessa forma, a correção prematura, permitindo a empresa economizar muito dinheiro com esforço em manutenções futuras.

O quanto é esse muito?

Quando estamos lidando com dinheiro, precisamos quantificar com precisão o que está envolvido. E, Dave Nicolette, fez isso de forma brilhante neste artigo, baseado em sua experiência. No artigo, ele mostra com números, a realidade de uma empresa que adota a programação em pares no seu dia-a-dia.

Sites relacionados:
InfoQ

[Noticia] Como o TDD e a programação em par aumentam a produtividade

Bem, acredito que vai ser difícil achar uma notícia que esteja mais no contexto desse blog que essa. O conteúdo dessa matéria da InfoQ diz tudo que eu sempre debati com as pessoas que questionam a necessidade de um software de qualidade.

Como diz o grande Shoes, Programadores Profissionais Escrevem Testes, Ponto Final.

Isso deveria ser óbvio, mas infelizmente, não é. Nas grandes empresas, onde existe divisão de papéis, quase sempre bem definida, conhecemos desenvolvedores dizendo que não tem a responsabilidade de testar.

O fato da empresa possuir uma equipe de testes, não exime o programador de testar o que fez. Verificar se o que foi implementado cumpre os requisitos é obrigação de todo desenvolvedor. Leia o texto do Philipp e tente não se convencer disso.

Uma suite de testes bem feita garante a qualidade do trabalho do profissional e, parodiando o Shoes, ponto final.

A questão do pair-programming já é um pouco mais complicada, já que envolve a alocação de dois colaboradores da empresa para a mesma tarefa. Essa técnica pode gerar discussões como: É impossível escrever todo o código em pares. Será muito lento. E se duas pessoas não se entenderem? A não ser que:

• Os padrões de codificação reduzam brigas mesquinhas;
• todo mundo esteja descansado e tranquilo, reduzindo mais ainda a chance de discussões não proveitosas;
• os pares escrevam testes juntos, o que dá a eles a chance de se sintonizarem antes de começarem a implementação;
• os pares tenham a metáfora para apoiar suas decisões sobre nomeação e projeto básico;
• os pares estejam trabalhando com um projeto simples, para que os dois entendam o que está acontecendo.

Trecho retirado do livro Programação Extrema Explicada - Kent Beck.

O próximo artigo da série princípios de projeto está quase pronto. Será abordada a questão da eficiência.

Sites Relacionados:
Fonte da Notícia: InfoQ