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 global
O 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 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
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 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
???
Top Related