Upload
internet
View
110
Download
4
Embed Size (px)
Citation preview
Extreme Programming
Walfredo Cirne
Universidade Federal de Campina Grande
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
Aspectos Fundamentais de XP
• Refatoramento
• Testes automáticos
Refatoramento
• Refatorar é melhorar o código sem alterar sua funcionalidade
• Antes de 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
JUnit
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 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
Documento = Código
• Codificação é a atividade central do projeto
• Testes (que também são código) servem de especificação
• Comunicação oral entre desenvolvedores, baseada no código (testes e funcionalidade) que descreve o sistema
Aspectos Importantes de XP
• Design mais simples possível
• Programação em pares
• Propriedade coletiva do código
• Cliente sempre disponível
• Estórias do usuário
• Planejamento do release
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
O Design Mais Simples Possível
• O melhor design é aquele que:– Roda todos os testes– Não contém duplicação de funcionalidade– Deixa claro as decisões de design importantes– Tem o menor número possível de classes e
métodos
• O melhor design não é aquele:– Mais flexível (com mais “ganchos”)– Mais abstrato– Que resistirá ao tempo
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
Propriedade Coletiva do Código
• Desenvolvimento com objetos leva a alterações por todo o código
• Coordenar alterações toma tempo e gera resistências no “dono” do código
• Em XP, não se coordena, simplesmente faz-se o que precisa ser feito
• Mas integra-se freqüentemente– No máximo, uma vez por dia
Propriedade Coletiva do Código
• Todos são responsável por todo o código
• Qualquer um que vê uma oportunidade de adicionar valor ao código, devo fazê-lo– Mantendo em vista as prioridades do cliente– Mantendo o design mais simples possível
• Testes protegem a funcionalidade
• Padrão de codificação evita a “guerra dos parênteses”
Cliente Sempre Disponível
• Um cliente (usuário da aplicação) deve trabalhar com o time para esclarecer dúvidas, resolver disputas e estabelecer pequenas prioridades
• É muito caro colocar um cliente a disposição do desenvolvimento?
• Talvez então não valha a pena fazer o sistema
Estórias
• 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
• Cliente decide:– escopo– prioridade– composição do release– data do release
• Programadores decidem:– estimativas– conseqüências– processo– planejamento intra-release
(o mais arriscado primeiro)
Releases
• 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
• 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
Valores de XP
• Simplicidade
• Comunicação
• Feedback
• Coragem
Simplicidade e Comunicação
Simplicidade
Comunicação
clarezaconfiança
menos a comunicarmais completo
Feedback
• Feedback possibilita que o software evolva
• “Pergunte ao software, não a um documento”
• Feedback precisa ser:– Cedo (pra gente descobrir logo se está fazendo
a coisa correta)– Concreto (feedback oriundo do código)– Constante (o ciclo de desenvolvimento tem que
ser curto)
Coragem
• Colocar o cliente a par do que tá acontecendo
• Acreditar na capacidade de responder a mudanças
• Aprender com os erros
• Acreditar no feedback (não na “teoria”)
• Jogar pra ganhar (não pra ter uma desculpa)
• Fazer o que precisa ser feito– Jogar fora código ruim
Dificuldades em XP
• Considerar testes como parte normal do processo de desenvolvimento
• Sempre fazer a coisa mais simples
• Admitir que você não sabe
• Colaborar
• Vencer resistência nas pessoas
Problemas de XP
• Times grandes
• Situações em que você não pode mudar livremente o código
• Escrever testes para sistemas não-deterministicos, distribuídos ou paralelos
Concluindo, use XP se você...
• tem que lidar com mudanças freqüentes
• se depara com requerimentos vagos
• valoriza resultado mais que cerimônia
• valoriza trabalho em equipe mais que “poder”
Como fica Engenharia de Software?• Dificuldades no Desenvolvimento de SW
– Complexidade + detalhes – Especificações vagas– Mutabilidade
• Soluções– Ênfase no projeto, métodos formais– Modularização– Revisão– Testes
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.xispe.com.br/index.html• http://www.extremeprogramming.org• http://www.xprogramming.com• http://www.martinfowler.com/articles/
newMethology.html• http://www.pairprogramming.com• http://www.junit.org
Referências Futuras
• http://www.objectmentor.com/ publications/RUPvsXP.pdf
• http://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm