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 testesEsta 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 coletivoNo 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 pessoas e caso algo nao esteja claro, com certeza sera alterado por alguma pessoa ( refactoring ) para que o mesmo torne-se legivel.2.2.8 Padroes de desenvolvimentoUm dos valores do XP e a comunicacao, e o codigo tambem e uma forma da equipe se comunicar. Uma forma clara de se comunicar atraves do codigo, e manter um padrao no projeto para que qualquer um possa rapidamente entender o codigo lido.O XP recomenda a adocao de um padrao desde o inicio do projeto, preferencialmente padroes utilizados pela comunidade da linguagem de desenvolvimento. Havendo a necessidade de modificacoes e adaptacoes durante o projeto,