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
1
Prelúdio
Programming in the Small
vs.
Programming in the Large
15 / Maio / 2001
Copyleft by Fabio Kon
2
Programação eXtrema
XP

Metodologia de desenvolvimento de
software aperfeiçoada nos últimos 5 anos.

Ganhou notoriedade a partir da
OOPSLA’2000.

Nome principal: Kent Beck.
15 / Maio / 2001
Copyleft by Fabio Kon
3
Reações a XP

Alguns odeiam, outros amam.
Quem gosta de programar ama!
 Deixa o bom programador livre para fazer
o que ele faria se não houvesse regras.
 Força o [mau] programador a se
comportar de uma forma similar ao bom
programador.

15 / Maio / 2001
Copyleft by Fabio Kon
4
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
15 / Maio / 2001
Copyleft by Fabio Kon
5
Premissas Básicas do
Modelo Tradicional

É necessário fazer uma análise de requisitos
profunda e detalhada antes de desenhar a
arquitetura do sistema.

É necessário fazer um estudo minucioso e
elaborar uma descrição detalhada da
arquitetura antes de começar a implementá-la.

É necessário testar o sistema completamente
antes de mandar a versão final para o cliente.
15 / Maio / 2001
Copyleft by Fabio Kon
6
Custo de mudanças
O que está por trás deste
modelo?
requisitos
desenho
testes
análise
implementação produção
15 / Maio / 2001
Copyleft by Fabio Kon
7
Custo de mudanças
E se a realidade hoje em
dia fosse outra?
tempo
15 / Maio / 2001
Copyleft by Fabio Kon
8
E se essa fosse a realidade?

A atitude dos desenvolvedores de
software seria completamente diferente:
Tomaríamos as grandes decisões o mais tarde
possível.
 Implementaríamos agora somente o que
precisamos agora.
 Não implementaríamos flexibilidade
desnecessária (não anteciparíamos
necessidades).

15 / Maio / 2001
Copyleft by Fabio Kon
9
E essa é a nova realidade !
(pelo menos em muitos casos)
Orientação a Objetos: facilita e cria
oportunidades para mudanças.
 Desenho simples: Less is more.
 Testes automatizados: nos dão
segurança quando fazemos mudanças.
 Prática / cultura de mudanças:
aprendemos técnicas e adquirimos
experiência em lidar com código mutante.

15 / Maio / 2001
Copyleft by Fabio Kon
10
A Quem se Destina XP?
Grupos de 2 a 10 programadores
 Projetos de 1 a 36 meses (calendário)
 De 1000 a 250 000 linhas de código
 Papéis:

Programadores (foco central)(sem hierarquia)
 “Treinador” (coach)
 “Acompanhador” (tracker)
 Cliente

15 / Maio / 2001
Copyleft by Fabio Kon
11
E Se Eu Não Me Encaixo
Nesses Casos?
Você ainda pode aprender muito sobre
desenvolvimento de software.
 Terá elementos para repensar as suas
práticas.



“Ou você é 100% eXtremo ou não é eXtremo.
Não dá prá ser 80% XP.”
XP is now like teenage sex.
15 / Maio / 2001
Copyleft by Fabio Kon
12
Princípios Básicos de XP

Feedback rápido

Simplicidade é o melhor negócio

Mudanças incrementais

Carregue a bandeira das mudanças
(Embrace change)

Alta qualidade
15 / Maio / 2001
Copyleft by Fabio Kon
13
As 4 Variáveis do
Desenvolvimento de Software

Tempo

Custo

Qualidade

Escopo (foco principal de XP)
15 / Maio / 2001
Copyleft by Fabio Kon
14
Um Projeto XP

Fase de Exploração
duração: 2 a 6 meses.
 termina quando a primeira versão do
software é enviada ao cliente.
 clientes escrevem “historias” (story cards).
 programadores interagem com clientes e
discutem tecnologias.
 Não só discutem, experimentam diferentes
tecnologias e arquiteturas para o sistema.
 Planejamento: 1 a 2 dias.

15 / Maio / 2001
Copyleft by Fabio Kon
15
Um Dia na Vida de um
Programador XP
Escolhe uma história do cliente.
 Procura um par livre.
 Escolhe um computador para programação
pareada (pair programming).
 Seleciona uma tarefa claramente
relacionada a uma característica (feature)
desejada pelo cliente.

15 / Maio / 2001
Copyleft by Fabio Kon
16
Um Dia na Vida de um
Programador XP

Discute modificações recentes no sistema

Discute história do cliente

Testes

Implementação

Desenho

Integração
15 / Maio / 2001
Copyleft by Fabio Kon
17
Um Dia na Vida de um
Programador XP

Atos constantes no desenvolvimento:
Executa testes antigos.
 Busca oportunidades para simplificação.
 Modifica desenho e implementação
incrementalmente baseado na funcionalidade
exigida no momento.
 Escreve novos testes.
 Enquanto todos os testes não rodam a 100%,
o trabalho não está terminado.
 Integra novo código ao repositório.

15 / Maio / 2001
Copyleft by Fabio Kon
18
Os 4 Valores de XP

Comunicação

Simplicidade

Feedback

Coragem
15 / Maio / 2001
Copyleft by Fabio Kon
19
Testes
Fundamento mais importante de XP.
 É o que dá segurança e coragem ao grupo.


Unit tests


escritos pelos programadores para testar cada
elemento do sistema (e.g., cada método em
cada caso).
Functional tests

escritos pelos clientes para testar a
funcionalidade do sistema.
15 / Maio / 2001
Copyleft by Fabio Kon
20
Testes

Unit tests
Tem que estar sempre funcionando a 100%.
 São executados várias vezes por dia.
 Executados à noite automaticamente.


Functional tests
Vão crescendo de 0% a 100%.
 Quando chegam a 100% acabou o projeto.

15 / Maio / 2001
Copyleft by Fabio Kon
21
O Código
Padrões de estilo adotados pelo grupo
inteiro.
 O mais claro possível.


XP não se baseia em documentações
detalhadas e extensas (perde-se sincronia).
Comentários sempre que necessários.
 Comentários padronizados.
 Programação Pareada ajuda muito!

15 / Maio / 2001
Copyleft by Fabio Kon
22
Programação Pareada
Erro de um detectado imediatamente pelo
outro (grande economia de tempo).
 Maior diversidade de idéias, técnicas,
algoritmos.
 Enquanto um escreve, o outro pensa em
contra-exemplos, problemas de eficiência, etc.
 Vergonha de escrever código feio (hacking) na
frente do seu par.
 Pareamento de acordo com especialidades.


Ex.: Sistema de Tempo Real Orientado a Objetos
15 / Maio / 2001
Copyleft by Fabio Kon
23
Propriedade Coletiva
do Código
Modelo tradicional: só autor de uma função
pode modificá-la.
 XP: o código pertence a todos.
 Se alguém identifica uma oportunidade
para simplificar, consertar ou melhorar
código escrito por outra pessoa, que o faça.
 Mas rode os testes!

15 / Maio / 2001
Copyleft by Fabio Kon
24
Refatoramento
(Refactoring)
Uma [pequena] modificação no sistema
que não altera o seu comportamento
funcional
 mas que melhora alguma qualidade nãofuncional:

simplicidade
 flexibilidade
 clareza
 desempenho

15 / Maio / 2001
Copyleft by Fabio Kon
25
Exemplos de
Refatoramento

Mudança do nome de variáveis

Mudanças nas interfaces dos objetos

Pequenas mudanças arquiteturais

Encapsular código repetido em um novo
método

Generalização de métodos

raizQuadrada(float x) raiz(float x, int n)
15 / Maio / 2001
Copyleft by Fabio Kon
26
Cliente
Responsável por escrever “histórias”.
 Muitas vezes é um programador ou é
representado por um programador do grupo.
 Trabalha no mesmo espaço físico do grupo.
 Novas versões são enviadas para produção
todo mês (ou toda semana).
 Feedback do cliente é essencial.
 Requisitos mudam (e isso não é mau).

15 / Maio / 2001
Copyleft by Fabio Kon
27
Coach
(treinador)
Em geral, o mais experiente do grupo.
 Identifica quem é bom no que.
 Lembra a todos as regras do jogo (XP).
 Eventualmente faz programação pareada.
 Não desenha arquitetura, apenas chama a
atenção para oportunidades de melhorias.
 Seu papel diminui à medida em que o
time fica mais maduro.

15 / Maio / 2001
Copyleft by Fabio Kon
28
Tracker
(Acompanhador)
A “consciência” do time.
 Coleta estatísticas sobre o andamento do
projeto. Alguns exemplos:

Número de historias definidas e implementadas.
 Número de unit tests.
 Número de testes funcionais definidos e
funcionando.
 Número de classes, métodos, linhas de código

Mantém histórico do progresso.
 Faz estimativas para o futuro.

15 / Maio / 2001
Copyleft by Fabio Kon
29
Quando XP Não Deve Ser
Experimentada?
Quando o cliente não aceita as regras do
jogo.
 Quando o cliente quer uma especificação
detalhada do sistema antes de começar.
 Quando os programadores não estão
dispostos a seguir (todas) as regras.
 Se (quase) todos os programadores do time
são medíocres.

15 / Maio / 2001
Copyleft by Fabio Kon
30
Quando XP Não Deve Ser
Experimentada?
Grupos grandes (>10 programadores).
 Quando feedback rápido não é possível:

sistema demora 6h para compilar.
 testes demoram 12h para rodar.
 exigência de certificação que demora meses.

Quando o custo de mudanças é
essencialmente exponencial.
 Quando não é possível realizar testes.

15 / Maio / 2001
Copyleft by Fabio Kon
31
Conclusão
Vencendo os Medos
Escrever código.
 Mudar de idéia.
 Ir em frente sem saber tudo sobre o futuro.
 Confiar em outras pessoas.
 Mudar a arquitetura de um sistema em
funcionamento.
 Escrever testes.

15 / Maio / 2001
Copyleft by Fabio Kon
32
Conclusão

XP não é para todo mundo.

Mas todo mundo pode aprender com ela.
15 / Maio / 2001
Copyleft by Fabio Kon
33