1 Programação eXtrema uma solução radical Seminário de Engenharia de Software Fabio Kon Departamento de Ciência da Computação 15 de maio de 2001.

Apresentação em tema: "1 Programação eXtrema uma solução radical Seminário de Engenharia de Software Fabio Kon Departamento de Ciência da Computação 15 de maio de 2001."— Transcrição da apresentação:

1 1 Programação eXtrema uma solução radical Seminário de Engenharia de Software Fabio Kon Departamento de Ciência da Computação 15 de maio de 2001

2 15 / Maio / 2001 Copyleft by Fabio Kon2 Prelúdio Programming in the Small vs. Programming in the Large

3 15 / Maio / 2001 Copyleft by Fabio Kon3 Programação eXtrema XP l Metodologia de desenvolvimento de software aperfeiçoada nos últimos 5 anos. l Ganhou notoriedade a partir da OOPSLA’2000. l Nome principal: Kent Beck.

4 15 / Maio / 2001 Copyleft by Fabio Kon4 Reações a XP l Alguns odeiam, outros amam. l Quem gosta de programar ama! l Deixa o bom programador livre para fazer o que ele faria se não houvesse regras. l Força o [mau] programador a se comportar de uma forma similar ao bom programador.

5 15 / Maio / 2001 Copyleft by Fabio Kon5 Modelo Tradicional de Desenvolvimento de Software 0. Levantamento de Requisitos 1. Análise de Requisitos 2. Desenho da Arquitetura 3. Implementação 4. Testes 5. Produção / Manutenção

6 15 / Maio / 2001 Copyleft by Fabio Kon6 Premissas Básicas do Modelo Tradicional l É necessário fazer uma análise de requisitos profunda e detalhada antes de desenhar a arquitetura do sistema. l É necessário fazer um estudo minucioso e elaborar uma descrição detalhada da arquitetura antes de começar a implementá-la. l É necessário testar o sistema completamente antes de mandar a versão final para o cliente.

7 15 / Maio / 2001 Copyleft by Fabio Kon7 O que está por trás deste modelo? Custo de mudanças requisitos desenho testes análise implementação produção

8 15 / Maio / 2001 Copyleft by Fabio Kon8 E se a realidade hoje em dia fosse outra? Custo de mudanças tempo

9 15 / Maio / 2001 Copyleft by Fabio Kon9 E se essa fosse a realidade? l A atitude dos desenvolvedores de software seria completamente diferente: l Tomaríamos as grandes decisões o mais tarde possível. l Implementaríamos agora somente o que precisamos agora. l Não implementaríamos flexibilidade desnecessária (não anteciparíamos necessidades).

10 15 / Maio / 2001 Copyleft by Fabio Kon10 E essa é a nova realidade ! (pelo menos em muitos casos) l Orientação a Objetos: facilita e cria oportunidades para mudanças. l Desenho simples: Less is more. l Testes automatizados: nos dão segurança quando fazemos mudanças. l Prática / cultura de mudanças: aprendemos técnicas e adquirimos experiência em lidar com código mutante.

11 15 / Maio / 2001 Copyleft by Fabio Kon11 A Quem se Destina XP? l Grupos de 2 a 10 programadores l Projetos de 1 a 36 meses (calendário) l De 1000 a 250 000 linhas de código l Papéis: l Programadores (foco central)(sem hierarquia) l “Treinador” (coach) l “Acompanhador” (tracker) l Cliente

12 15 / Maio / 2001 Copyleft by Fabio Kon12 E Se Eu Não Me Encaixo Nesses Casos? l Você ainda pode aprender muito sobre desenvolvimento de software. l Terá elementos para repensar as suas práticas. l “Ou você é 100% eXtremo ou não é eXtremo. Não dá prá ser 80% XP.” l XP is now like teenage sex.

13 15 / Maio / 2001 Copyleft by Fabio Kon13 Princípios Básicos de XP l Feedback rápido l Simplicidade é o melhor negócio l Mudanças incrementais l Carregue a bandeira das mudanças (Embrace change) l Alta qualidade

14 15 / Maio / 2001 Copyleft by Fabio Kon14 As 4 Variáveis do Desenvolvimento de Software l Tempo l Custo l Qualidade l Escopo (foco principal de XP)

15 15 / Maio / 2001 Copyleft by Fabio Kon15 Um Projeto XP l Fase de Exploração l duração: 2 a 6 meses. l termina quando a primeira versão do software é enviada ao cliente. l clientes escrevem “historias” (story cards). l programadores interagem com clientes e discutem tecnologias. l Não só discutem, experimentam diferentes tecnologias e arquiteturas para o sistema. l Planejamento: 1 a 2 dias.

16 15 / Maio / 2001 Copyleft by Fabio Kon16 Um Dia na Vida de um Programador XP l Escolhe uma história do cliente. l Procura um par livre. l Escolhe um computador para programação pareada (pair programming). l Seleciona uma tarefa claramente relacionada a uma característica (feature) desejada pelo cliente.

17 15 / Maio / 2001 Copyleft by Fabio Kon17 Um Dia na Vida de um Programador XP l Discute modificações recentes no sistema l Discute história do cliente l Testes l Implementação l Desenho l Integração

18 15 / Maio / 2001 Copyleft by Fabio Kon18 Um Dia na Vida de um Programador XP l Atos constantes no desenvolvimento: l Executa testes antigos. l Busca oportunidades para simplificação. l Modifica desenho e implementação incrementalmente baseado na funcionalidade exigida no momento. l Escreve novos testes. l Enquanto todos os testes não rodam a 100%, o trabalho não está terminado. l Integra novo código ao repositório.

19 15 / Maio / 2001 Copyleft by Fabio Kon19 Os 4 Valores de XP l Comunicação l Simplicidade l Feedback l Coragem

20 15 / Maio / 2001 Copyleft by Fabio Kon20 Testes l Fundamento mais importante de XP. l É o que dá segurança e coragem ao grupo. l Unit tests l escritos pelos programadores para testar cada elemento do sistema (e.g., cada método em cada caso). l Functional tests l escritos pelos clientes para testar a funcionalidade do sistema.

21 15 / Maio / 2001 Copyleft by Fabio Kon21 Testes l Unit tests l Tem que estar sempre funcionando a 100%. l São executados várias vezes por dia. l Executados à noite automaticamente. l Functional tests l Vão crescendo de 0% a 100%. l Quando chegam a 100% acabou o projeto.

22 15 / Maio / 2001 Copyleft by Fabio Kon22 O Código l Padrões de estilo adotados pelo grupo inteiro. l O mais claro possível. l XP não se baseia em documentações detalhadas e extensas (perde-se sincronia). l Comentários sempre que necessários. l Comentários padronizados. l Programação Pareada ajuda muito!

23 15 / Maio / 2001 Copyleft by Fabio Kon23 Programação Pareada l Erro de um detectado imediatamente pelo outro (grande economia de tempo). l Maior diversidade de idéias, técnicas, algoritmos. l Enquanto um escreve, o outro pensa em contra-exemplos, problemas de eficiência, etc. l Vergonha de escrever código feio (hacking) na frente do seu par. l Pareamento de acordo com especialidades. l Ex.: Sistema de Tempo Real Orientado a Objetos

24 15 / Maio / 2001 Copyleft by Fabio Kon24 Propriedade Coletiva do Código l Modelo tradicional: só autor de uma função pode modificá-la. l XP: o código pertence a todos. l Se alguém identifica uma oportunidade para simplificar, consertar ou melhorar código escrito por outra pessoa, que o faça. l Mas rode os testes!

25 15 / Maio / 2001 Copyleft by Fabio Kon25 Refatoramento (Refactoring) l Uma [pequena] modificação no sistema que não altera o seu comportamento funcional l mas que melhora alguma qualidade não- funcional: l simplicidade l flexibilidade l clareza l desempenho

26 15 / Maio / 2001 Copyleft by Fabio Kon26 Exemplos de Refatoramento l Mudança do nome de variáveis l Mudanças nas interfaces dos objetos l Pequenas mudanças arquiteturais l Encapsular código repetido em um novo método l Generalização de métodos l raizQuadrada(float x)  raiz(float x, int n)

27 15 / Maio / 2001 Copyleft by Fabio Kon27 Cliente l Responsável por escrever “histórias”. l Muitas vezes é um programador ou é representado por um programador do grupo. l Trabalha no mesmo espaço físico do grupo. l Novas versões são enviadas para produção todo mês (ou toda semana). l Feedback do cliente é essencial. l Requisitos mudam (e isso não é mau).

28 15 / Maio / 2001 Copyleft by Fabio Kon28 Coach (treinador) l Em geral, o mais experiente do grupo. l Identifica quem é bom no que. l Lembra a todos as regras do jogo (XP). l Eventualmente faz programação pareada. l Não desenha arquitetura, apenas chama a atenção para oportunidades de melhorias. l Seu papel diminui à medida em que o time fica mais maduro.

29 15 / Maio / 2001 Copyleft by Fabio Kon29 Tracker (Acompanhador) l A “consciência” do time. l Coleta estatísticas sobre o andamento do projeto. Alguns exemplos: l Número de historias definidas e implementadas. l Número de unit tests. l Número de testes funcionais definidos e funcionando. l Número de classes, métodos, linhas de código l Mantém histórico do progresso. l Faz estimativas para o futuro.

30 15 / Maio / 2001 Copyleft by Fabio Kon30 Quando XP Não Deve Ser Experimentada? l Quando o cliente não aceita as regras do jogo. l Quando o cliente quer uma especificação detalhada do sistema antes de começar. l Quando os programadores não estão dispostos a seguir (todas) as regras. l Se (quase) todos os programadores do time são medíocres.

31 15 / Maio / 2001 Copyleft by Fabio Kon31 Quando XP Não Deve Ser Experimentada? l Grupos grandes (>10 programadores). l Quando feedback rápido não é possível: l sistema demora 6h para compilar. l testes demoram 12h para rodar. l exigência de certificação que demora meses. l Quando o custo de mudanças é essencialmente exponencial. l Quando não é possível realizar testes.

32 15 / Maio / 2001 Copyleft by Fabio Kon32 Conclusão Vencendo os Medos l Escrever código. l Mudar de idéia. l Ir em frente sem saber tudo sobre o futuro. l Confiar em outras pessoas. l Mudar a arquitetura de um sistema em funcionamento. l Escrever testes.

33 15 / Maio / 2001 Copyleft by Fabio Kon33 Conclusão l XP não é para todo mundo. l Mas todo mundo pode aprender com ela.