extreme programming walfredo cirne universidade federal da paraíba
TRANSCRIPT
Extreme Programming
Walfredo Cirne
Universidade Federal da Paraíba
Engenharia de Software
• Desenvolvimento ad-hoc de software em geral produz resultados muito ruins– Especialmente em sistemas grandes
• Desejo de criar uma engenharia para que se tenha controle sobre desenvolvimento de software
• Engenharias tradicionais colocam grande ênfase em projetar antes de construir
Visão Tradicional da Evolução do Software
custo
momento em quefuncionalidade éadicionada
Queremos Poder Alterar Software
• No inicio do projeto, normalmente não se sabe precisamente o que se quer
• Software evolui para atender ao business– Software nunca fica “pronto”
• Obviamente isso só é possível porque software é uma entidade abstrata
Portanto…
• Precisamos parar de tentar evitar mudanças– Mudanças são um aspecto intrínseco da vida
do software
• Precisamos de uma metodologia de desenvolvimento que nos permita alterar constantemente o código sem comprometer sua qualidade
O que queremos é…
custo
momento em quefuncionalidade éadicionada
Extreme Programming (XP)
• Viva a mudança!!!
• Desenvolvimento de software é … – um aprendizado – como dirigir um carro
• Desenvolvimento de software não é …– como construir uma ponte– aponte e atire
Extreme Programming (XP)
• Codificação é a atividade central do projeto
• Testes (que também é código) servem de especificação
• Comunicação entre desenvolvedores se baseia em código
Valores de XP
• Simplicidade
• Comunicação
• Feedback
• Agressividade
O Mantra do Programador XP
• Codifique, senão o software não sai• Teste, senão você não sabe se está
funcionando• Refatore, senão o código vai ficar tão ruim
que será impossível dar manutenção• Escute, para que saiba qual é o problema
a resolver• Planeje, para que você sempre faça a
coisa mais importante ainda a fazer
Aspectos Fundamentais de XP
• Refatoramento
• Testes automáticos
• Design mais simples possível
• Programação em pares
• Estórias do usuário
• Planejamento do release
Refatoramento
• Refatorar é melhorar o código sem alterar sua funcionalidade
• Antes de fazer uma mudança, você refatora o código para que a mudança seja simples de fazer
• Refatoração continua possibilita manter um design legal, mesmo com mudanças freqüentes
Testes Automáticos
• Testes automáticos são parte do software– Se você tem somente a funcionalidade, seu software
está incompleto
• Testes permitem que você refatore sem medo de quebrar o código
• Testes representam uma “redundância lógica” que você adiciona ao código
• Escrevendo testes antes da funcionalidade, você clareia dúvidas sobre o que o software deve fazer
• Testes de unidade x testes funcionais
O Livro de Refatoração
• “Refactoring: Improving the Design of Existing Code”, escrito por Martin Fowler, contém dezenas de “receitas de refatoração”
• Se você ainda não sabe, este livro vai te ensinar Orientação a Objetos– Por exemplo, teu código tem switches em
atributos de tipo?
Código Não-OO
int JobSpec::requests(){if( js_type == jst_fixed ){
return 1;} else if( js_type == jst_downey ){
return js_options;} else if( js_type == jst_nas ){
fatal( “not implemented yet" );} else {
fatal1( "unknown js_type: %s", js_type );}return 0; // this avoids a warning
}
Código OO
…class DowneyJobSpec: public JobSpec {
…int requests(){
return js_options;};…
}…
O Design Mais Simples Possível
• Designs flexíveis são uma defesa contra mudanças imprevistas no software
• Porém, designs flexíveis também têm custos– Tempo para desenvolvimento e manutenção– O código fica mais complexo– Muita vezes a flexibilidade não é utilizada nunca
• Como mudança é barata em XP, vamos manter o design mais simples possível, modificando-o quando for necessário suportar mais funcionalidade
Programando em Pares
• Se revisão de código é legal, vamos fazê-la o tempo todo
• Em XP, programação é feita em pares• Pares mudam com relativa rapidez (em dias)• Programação em pares favorece comunicação e
aprendizado• Mas, você precisa estabelecer um padrão de
codificação• Há casos de redução no tempo de
desenvolvimento com programação em pares
O Jogo do Planejamento
• Usuários escrevem estórias descrevendo a funcionalidade que querem
• Desenvolvedores estimam o tempo necessário para implementar cada estória
• Um release é um conjunto de estórias que são disponibilizados simultaneamente– As estórias mais importantes e/ou mais difíceis
tem prioridade
O Jogo do Planejamento
• XP preconiza releases pequenos e freqüentes (a cada 2-3 meses)
• As quatro dimensões do desenvolvimento de software são Custo, Tempo, Qualidade e Escopo– XP tenta manter escopo como variável livre
Iterações
• Releases são divididas em iterações de 2-3 semanas
• Uma iteração alcança algum objetivo (tipicamente a adição de nova funcionalidade)
• Nada é feito que não seja imediatamente útil e necessário para não impactar os prazos de desenvolvimento
Tarefas
• Iterações são divididas em tarefas
• Tarefas são a menor quantidade de trabalho que pode ser feita até que todos os testes voltem a funcionar
• Tarefas não levam mais que um dia
• Uma vez concluídas, tarefas são integradas imediatamente
Outros Aspectos de XP
• Um cliente trabalha junto ao time de desenvolvimento em tempo integral
• Jogue pra ganhar
• Adapte para a situação em mão
• “Travel light”
• Estimativas baseadas na experiência
• Métricas customizadas
Outros Aspectos de XP
• Faça o mais arriscado primeiro
• Crie testes para cada bug encontrado
• Trabalhe a favor dos instintos dos programadores, não contra eles
• Responsabilidade é aceita, nunca imposta
• Hora extra rotineira não funciona
• Qualquer par pode alterar qualquer parte do código
Problemas de XP
• Grandes times
• Situações em que você não pode mudar livremente o código
Referências Futuras
• Extreme Programming Explained por Beck
• Extreme Programming Installed por Jeffries, Anderson e Hendrickson
• Planning Extreme Programming por Beck e Fowler
• Refactoring: Improving the Design of Existing Code por Fowler
• Design Patterns pela “Gangue dos Quatro”
Referências Futuras
• http://www.extremeprogramming.org• http://www.xprogramming.com• http://www.martinfowler.com/articles/
newMethology.html• http://www.objectmentor.com/
publications/RUPvsXP.pdf• http://www.pairprogramming.com• http://www.junit.org