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 pelo cliente e implementados pelos desenvolvedores, facilitando ainda mais a interacao entre as partes. 2.2.7 Codigo coletivo No modelo tradicional de desenvolvimento, e comum dividir o projeto em partes e colocar responsaveis por cada uma destas partes. Porem apenas uma pessoa torna-se conhecedora daquela parte. Este tipo de divisao traz serios problemas ao projeto, uma vez que se aquela parte necessitar inumeras alteracoes, apenas uma pessoa estara capacitada para altera-la. Com estas inumeras alteracoes, esta pessoa pode se tornar um gargalo no projeto. O XP trava uma batalha contra este tipo de divisao, ja que nao existe uma pessoa responsavel por uma parte do codigo. Cada desenvolvedor tem acesso a qualquer parte do sistema e tem liberdade para altera-la a qualquer momento e sem qualquer tipo de aviso. Esta pratica tem como consequencia um codigo revisado por diversas