Programação
Pragmática
Kleber Silva, [email protected]
11/10/2005
Agenda









Conceitos
O Programador Pragmático
Uma Abordagem Pragmática
As Ferramentas Básicas
A Paranóia Pragmática
Dobre ou Quebre
Antes da Implementação...
Testes
Conclusões
Conceitos
Criada por Andrew Hunt e David Thomas
em 1999
 Indica boas práticas de programação e
alerta para as maiores armadilhas na área
de desenvolvimento de software
 Principalmente
voltada
para
o
programador e para a equipe de
programação

O Programador Pragmático





Adoção Cedo/Adaptação Rápida – Tem um traquejo para tecnologias e
técnicas, e adora experimentar. Quando lhe é dado algo novo, pega com
facilidade e integra com o resto de seu conhecimento. Sua confiança nasce
da experiência.
Inquisitivo – Tende a fazer perguntas. Isso está legal, como você fez?
Você teve problemas com esta biblioteca?
Pensador Crítico – Raramente aceita as coisas de pronto sem primeiro
averiguar os fatos.
Realista – Tenta entender a natureza oculta de cada problema enfrentado.
Isso permite um “feeling” sobre o quão difícil as coisas são, ou quanto
tempo vai se levar.
Pau pra Toda a Obra. Esforça-se ao máximo para ter familiaridade com
uma grande gama de tecnologias e ambientes, trabalha para acompanhar
novos desenvolvimentos. Capaz de se mover para áreas novas, embora
com foco especialista.
O Programador Pragmático




Dica 1: Preocupe-se com suas habilidades
(expertise);
Dica 2: Pense no seu trabalho;
Dica 3: Dê opções, não venha com desculpas
esfarrapadas (the cat ate my source code);
Dica 4: Não viva com janelas quebradas;
O Programador Pragmático

Dica 5: Seja
mudanças
um
catalisador
A Sopa de Pedra
de
O Programador Pragmático

Dica 6: Lembre-se do contexto global
O Sapo Cozido
O Programador Pragmático

Dica 7: Faça da qualidade
importante nos requisitos
um
ponto
Good Enough Software
Striving to better, oft we mar what´s well.
King Lear 1.4
O Programador Pragmático

Dica 8: Invista regularmente em seu portfólio
de conhecimento

Aprenda pelo menos uma nova linguagem a cada
ano
 Leia um livro técnico a cada 4 meses
 Leia livros não técnicos também
 Participe em grupos de usuários locais
 Experimente diferentes ambientes
 Fique atualizado
 Antene-se
O Programador Pragmático


Dica 9: Analise com visão crítica o que
você lê e o que você ouve
Dica 10: É tanto o que você diz quanto a
forma como diz
Uma Abordagem Pragmática

Os males da duplicação
 Dica

11: DRY – Don´t Repeat YourSelf
Duplicação Imposta
Múltiplas Representações de Informações (Uso de
MetaDados)
 Documentação no Código
 Documentação e Código
 Issues de Linguagem- i.e. headers do C, C++


Duplicação por desatenção

Ex:
class Line {
public:
Point start;
Point end;
double length;
};
ou
class Line {
public:
Point start;
Point end;
double length() { return start.distanceTo(end); }
};
Uma Abordagem Pragmática

Os males da duplicação (continuação)
 Dica

Duplicação por Impaciência


11: DRY – Don´t Repeat YourSelf
“Shortcuts make for long delays”
Duplicação Interdesenvolvedores
 Dica
12: Facilite o Reuso
Uma Abordagem Pragmática

Ortogonalidade
 Tipo
de independência ou desacoplamento
Uma Abordagem Pragmática

Sistemas Não Ortogonais
Uma Abordagem Pragmática

Ortogonalidade
Dica 13: Elimine o efeito entre coisas não
relacionadas
 Produz ganhos de produtividade
 Facilita o Reuso
 Reduz Risco
 Aplicável a equipes de projeto
 Design
 Toolkits e ferramentas

Uma Abordagem Pragmática

Ortogonalidade

Código



Mantenha desacoplado
Evite dados globais
Evite funções similares
 Teste

É facilitado
 Documentação

Separação conteúdo e apresentação
Uma Abordagem Pragmática

Reversibilidade
 Tudo
muda
 Dica 14: Não há decisões finais (irredutíveis)
 Arquitetura Flexível
O gato de Schrodinger
Uma Abordagem Pragmática

Tracer Bullet
 Usado
para construção de algo novo: i.e.
tecnologias, técnicas, linguagens e algoritmos
 Dica 15: Use Tracer Bullets para encontrar o
alvo
 Abordagem incremental
Uma Abordagem Pragmática

Tracer Bullet
 Vantagens






Os usuários conseguem ver algo funcionando cedo
Os desenvolvedores constroem uma estrutura para trabalhar
Você tem uma plataforma de integração
Você tem algo para demonstrar
Você tem um maior sentimento de progresso
Tracer Bullets vs Prototype
 Dica
16: Use Protótipos para aprender.
Uma Abordagem Pragmática

Linguagens do Domínio


Estimativas



Dica 17: Programe perto do Domínio do Problema
Dica 18: Estime para evitar surpresas
Qual o grau de acurácia necessário?
Estimativas de Cronograma de Projeto


“The normal rules of estimating can break down in the face of the
complexities and vagaries of a sizable application development.
We find that often the only way to determine the timetable for a
project is by gaining experience on that same project.”, The
Pragmatic Programmer
Dica 19: Itere o cronograma com o código
As Ferramentas Básicas









Dica 20: Mantenha o Conhecimento em Plain Text
Dica 21: Use o poder dos Command Shells
Dica 22: Use bem um único editor
Dica 23: Sempre use Controle de Versão de Código
Fonte
Dica 24: Fixe-se no problema, não nos culpados
Dica 25: Não entre em pânico
Dica 26: o "select" não está “buggado”
Dica 27: Não assuma – prove
Dica 28: Aprenda uma Linguagem de Manipulação
As Ferramentas Básicas

Geradores de Código
– Uma única vez
 Ativo – Toma uma representação e converte
em código. Quando a representação muda,
novo código é gerado
 Dica 29: Escreva código que escreva código
 Passivo
A Paranóia Pragmática

Dica 30: Você não pode escrever software perfeito


Dica 31: Design with Contracts (DBC)







O Programador Pragmático desconfia de si próprio.
Précondições
Póscondições
Invariantes de classe
Dica 32: Crash Early
Dica 33: Se não pode acontecer. Use Assertions pra garantir que
não vai.
Dica 34: Use exceções para casos excepcionais
Dica 35: Termine o que você começou. (C++ new, delete)
Dobre ou Quebre

Desacoplamento e a Lei de Demeter
 Dica
36: Minimize o acoplamento entre
módulos
Dobre ou Quebre




Design para concorrência, para serviços
Separar Views de Modelos (MVC)
Programação por coincidência
Refactoring


Wizards



Com uso de ferramentas (automático)
Não use se você não entende o código produzido!!
Design para testes
Foco em testes
Antes da Implementação...

Levantamento de Requisitos
 Trabalhe
com o usuário para pensar como ele
 Dicionário de dados em reuniões com
usuários
 Especificação de mini-linguagem
 Use Cases
Documentação formal ou informal?
 Poucos detalhes


Template para caso de uso - Cockburn
Template
1. CHARACTERISTIC INFORMATION
 Goal
in context
 Scope
 Level
 Preconditions
 Success end condition
 Failed end condition
 Primary actor
 Trigger
Template
2. MAIN SUCCESS SCENARIO
3. EXTENSIONS
4.VARIATIONS
5. SCHEDULE
6. OPEN ISSUES
Template
8.RELATED INFORMATION
 Priority
 Performance
target
 Frequency
 Superordinate
use case
 Subordinate use cases
 Channel to primary actor
 Secondary actor
 Channel to secondary actor
Template
Testes



Unitários
Integração
Validação e Verificação
 Dados
 Regressão



Testes de Performance
Testes de Usabilidade
Teste os testes!!!
 Cause
bugs
Conclusão





Não é só teoria, e sim uma abordagem da experiência
que normalmente dá certo na área de desenvolvimento;
Serve não somente para os programadores, mas
também para a gerência dos projetos que se beneficia
do conhecimento do que se deve fazer e do que deve
ser evitado
Promove
um
ganho
de
produtividade
aos
desenvolvedores
Promove um maior nível de formalidade no
levantamento de requisitos através do uso de templates
específicos
Metodologia com enfoque nos testes e no design.
Referências
Andrew Hunt, David Thomas, The
Pragmatic Programmer, Addison-Wesley,
2000
 www.pragmaticprogrammer.com

Dúvidas
???