Programação Pragmática

2.591 visualizações

Publicada em

Publicada em: Tecnologia, Educação
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
2.591
No SlideShare
0
A partir de incorporações
0
Número de incorporações
23
Ações
Compartilhamentos
0
Downloads
77
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Programação Pragmática

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

    ×