programação pragmática kleber silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005
Post on 07-Apr-2016
217 Views
Preview:
TRANSCRIPT
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 um catalisador de mudanças
A Sopa de Pedra
O Programador Pragmático
Dica 6: Lembre-se do contexto globalO Sapo Cozido
O Programador Pragmático Dica 7: Faça da qualidade um ponto
importante nos requisitos
Good Enough SoftwareStriving 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çãoDica 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;};
class Line {public:Point start;Point end;double length() { return start.distanceTo(end); }};
ou
Uma Abordagem Pragmática
Os males da duplicação (continuação)Dica 11: DRY – Don´t Repeat YourSelf
Duplicação por Impaciência “Shortcuts make for long delays”
Duplicação InterdesenvolvedoresDica 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
ReversibilidadeTudo mudaDica 14: Não há decisões finais (irredutíveis)Arquitetura Flexível
O gato de Schrodinger
Uma Abordagem Pragmática
Tracer BulletUsado para construção de algo novo: i.e.
tecnologias, técnicas, linguagens e algoritmosDica 15: Use Tracer Bullets para encontrar o
alvoAbordagem 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
Dica 17: Programe perto do Domínio do Problema Estimativas
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ódigoPassivo – Uma única vezAtivo – 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
A Paranóia Pragmática Dica 30: Você não pode escrever software perfeito
O Programador Pragmático desconfia de si próprio. Dica 31: Design with Contracts (DBC)
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 DemeterDica 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
Com uso de ferramentas (automático) Wizards
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 SCENARIO3. EXTENSIONS4.VARIATIONS5. SCHEDULE6. 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
???
top related