Walfredo Cirne Universidade Federal da Paraíba

Apresentação em tema: "Walfredo Cirne Universidade Federal da Paraíba"— Transcrição da apresentação:

1 Walfredo Cirne Universidade Federal da Paraíba
Extreme Programming Walfredo Cirne Universidade Federal da Paraíba

2 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

3 Visão Tradicional da Evolução do Software
custo momento em que funcionalidade é adicionada

4 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

5 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

6 O que queremos é… custo momento em que funcionalidade é adicionada

7 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

8 Valores de XP Simplicidade Comunicação Feedback Coragem

9 Simplicidade e Comunicação
clareza confiança menos a comunicar mais completo Comunicação

10 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)

11 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

12 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

13 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

14 Aspectos Fundamentais de XP
Refatoramento Testes automáticos 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

15 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

16 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

17 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?

18 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 }

19 Código OO … class DowneyJobSpec: public JobSpec { int requests(){
return js_options; }; }

20 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

21 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 “hooks”) Mais abstrato Que resistirá ao tempo

22 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

23 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

24 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”

25 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

26 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

27 O Jogo do Planejamento Business decide: Programadores decidem: escopo
prioridade composição do release data do release Programadores decidem: estimativas conseqüências processo planejamento intra-release (o mais arriscado primeiro)

28 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

29 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

30 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

31 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

32 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

33 Dificuldades em XP Sempre fazer a coisa mais simples
Admitir que você não sabe Colaborar Vencer resistência nas pessoas

34 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

35 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”

36 Como fica Engenharia de Software?
Dificuldades no Desenvolvimento de SW Complexidade + detalhes Especificações vagas Mutabilidade Soluções Ênfase no projeto, métodos formais Modularizar Revisão Testes

37 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”

38 Referências Futuras http://www.extremeprogramming.org
newMethology.html publications/RUPvsXP.pdf

39 Referências Futuras papers/pairprogrammingcostbene/ pairprogrammingcostbene.htm