IMUNOLOGIA VETERINÁRIA 2014 - 1 Profa. Elizabeth Obino Cirne Lima.
Extreme Programming Walfredo Cirne Universidade Federal da Paraíba.
Transcript of Extreme Programming Walfredo Cirne Universidade Federal da Paraíba.
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