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