codificacao muito mais simples e eficaz. e com esta pratica que o XP uniformiza o nivel dos desenvolvedores da equipe, atraves da troca de experiencias. Apos alguns meses trabalhando em duplas todos os desenvolvedores conhecerao todas rotinas do sistema, prontos para qualquer modificacao ou para auxiliar algum iniciante. Um grande questionamento sobre esta pratica e com questao a produtividade dos desenvolvedores. Porem, e um erro pensar que somente uma pessoa estara codificando enquanto o outro apenas observa. O membro que nao esta codificando nao apenas observa, mas tambem troca ideias, gera solucoes e evita praticamente todos erros de codificacao alem de cobrar padroes de desenvolvimento da equipe. Estudos indicam que a produtividade de uma equipe que utiliza pair programming e de equipes que tenham desenvolvedores sozinhos e praticamente a mesma, porem a qualidade do codigo gera facilidade de manutencao e outros ganhos a medio e longo prazo. 2.2.5 Refactoring Um desenvolvedor ao deparar com um codigo mal escrito ou pouco legivel mas que esteja funcionando, nos modelos tradicionais de desenvolvimento, dificilmente efetuaria alteracoes neste codigo, mesmo que tivesse que implementar novas funcionalidades. O XP prega que todo desenvolvedor ao encontrar um codigo duplicado, pouco legivel, mal codificado, sem padronizacao, lento, com codigo legado ou uso incorreto de outras implementacoes, tem por obrigacao alterar este codigo deixando-o mais legivel e simples, porem esta alteracao nao pode mudar o comportamento do codigo em questao. Esta pratica anda de maos dadas com o codigo coletivo, ja que todo desenvolvedor tem a possibilidade de melhorar qualquer codigo do sistema. A padronizacao oferece facilidades aos desenvolvedores no momento de implementar novas funcionalidades ou efetuar qualquer tipo de manutencao, uma vez que o codigo se encontra simples e claro. Uma questao importante e que a pratica de refactoring esta apoiada pelos testes automatizados, pois facilmente o desenvolvedor tera um feedback se a alteracao por ele efetuada ira gerar qualquer tipo de comportamento anormal no sistema, sofrendo o aprendizado sobre a alteracao por ele efetuada. 2.2.6 Desenvolvimento guiado por testes Esta atividade e considerada extremamente chata e dispendiosa por muitos desenvolvedores na modelagem tradicional, porem para os desenvolvedores de uma equipe XP esta atividade deve ser encarada com extrema naturalidade. Todo codigo implementando deve coexistir com um teste automatizado, assim garantindo o pleno funcionamento da nova funcionalidade. e com base nestes testes automatizados que qualquer desenvolvedor tera coragem para alterar uma parte do codigo que nao tenha sido implementada por ele, ja que executando os testes automatizados podera verificar instantaneamente se a modificacao efetuada alterou o comportamento do sistema. Com a implementacao de testes o desenvolvedor podera amadurecer o entendimento sobre o problema que ira solucionar, ja que os testes sao codificados antes da nova implementacao. No XP existem dois tipos de testes, os testes de unidade e de aceitacao. O teste de unidade tem por objetivo verificar se os resultados gerados por cada classe estao corretos, ja o teste de aceitacao tem por objetivo verificar se a interacao entre as classes que implementam uma funcionalidade (estoria) atendem a necessidade de forma correta. Os testes de aceitacao sao descritos