O programador pragmático

Prévia do material em texto

O Programador Pragmático
Andrew Hunt & David Thomas
Uma empresa
C.E.S.A.R
Tadeu Marinho
tadeu.marinho@pitang.com
Agenda
O Livro;
 Introdução;
Uma filosofia pragmática;
Uma abordagem pragmática;
As ferramentas básicas;
Paranóia pragmática;
Seja flexível;
Enquanto você está codificando;
Antes do projeto;
Projetos pragmáticos.
O Livro
 ISBN: 8577807002;
 ISBN-13: 9788577807000;
 Idioma: Livro em português;
Encadernação: Brochura;
 Idioma: Português;
Ano de Lançamento: 2009;
Número de páginas: 343. 
Definição
Pragmático:
–Do latim: pragmaticus - “Habilidoso no trabalho”;
–Do grego: “πραττειν” - “fazer”.
Desenvolvedores
Ser único:
–Pontos fortes e fracos;
–Preferências e aversões.
Programador Pragmático
Características:
–Adoção antecipada / adaptação rápida;
– Inquisitivo;
–Pensador crítico;
–Realista;
–Pau para toda obra.
Executam o trabalho e o executam bem!
Dica 1
Preocupe-se com seu trabalho.
Dica 2
Reflita sobre seu trabalho.
Kaizen
Projeto:
–Fazer continuamente diversas pequenas melhorias;
Pessoas:
–Empenhar-se continuamente em aprimorar as habilidades;
–Adicionar novas ferramentas às que já usa.
Uma Filosofia Pragmática
Dica 3
Forneça opções, não dê desculpas esfarrapadas.
Dica 4
Não tolere janelas quebradas.
Dica 5
Seja um catalisador da mudança.
Dica 6
Lembre-se do cenário em larga escala.
Dica 7
Torne a qualidade parte dos requisitos.
Dica 8
Invista regularmente em sua carteira de conhecimentos.
Carteira de Investimentos
 Investidores sérios investem regularmente, como um hábito;
A diversidade é a chave para o sucesso a longo prazo;
 Investidores astutos têm uma carteira equilibrada com 
investimentos conservadores e de alto risco e remuneração;
Os investidores tentam comprar barato e vender caro para 
obter o máximo de retorno;
As carteiras devem ser reexaminadas e reestruturadas 
periodicamente.
Carteira de Conhecimentos
 Invista regularmente;
Diversifique;
Gerencie o risco;
Compre barato, venda caro;
Reexamine e reestruture.
Sugestões
Aprenda pelo menos uma nova linguagem todo ano;
Leia um livro técnico a cada trimestre;
Leia também livros não técnicos;
Tenha aulas;
Participe de grupos de usuários locais;
Experimente ambientes diferentes;
Mantenha-se informado;
Mantenha-se conectado.
Dica 9
Analise criticamente o que você lê e ouve.
Pensamento Crítico
O cuidado e a consulta com especialistas:
–Saiba o que quer perguntar;
–Seja específico;
–Formule sua pergunta cuidadosamente e polidamente;
–Preciso de ajuda não é suficiente;
–Tenha paciência ao esperar um retorno.
Dica 10
É o que você diz e a maneira como diz.
Comunique-se
Saiba o que você quer dizer;
Conheça seu público-alvo;
Escolha seu momento;
Escolha um estilo;
Dê uma boa aparência.
Envolva seu público-alvo;
Seja um ouvinte;
Dê retorno às pessoas.
Seja ASTUTO
 O que você quer que eles Aprendam?
 Qual é Seu interesse no que você tem a dizer?
 Seu Trabalho tem que nível de sofisticação?
 Que nível de detalhes eles Usam?
 Quem você quer que Tenha a posse da informação?
Como você pode motivá-los a Ouví-lo?
Email
Releia;
Verifique a ortografia;
Mantenha um formato simples;
Correspondência formatada;
Crédito de citações;
Verifique a lista de destinatários.
Uma Abordagem Pragmática
Dica 11
NSR - Não se repita.
Os Males da Duplicação
Princípios NSR:
–Cada bloco de informações deve ter uma representação oficial, 
exclusiva e sem ambigüidades dentro de um sistema.
Como Surge a Duplicação
Duplicidade imposta:
–Acham que não tem escolhas - o ambiente parece pedir.
Duplicação inadvertida:
–Não percebem que estão duplicando informações.
Duplicação impaciente:
–Preguiça e duplicam porque parece ser mais fácil.
Duplicidade entre desenvolvedores:
–Várias pessoas duplicam por desconhecer o sistema como um todo.
Duplicidade Imposta
Várias representações das informações;
Documentação no código;
Documentação e código;
Problemas de linguagem;
Duplicação Impaciente
Atalhos causam grandes atrasos;
Fácil de detectar e manipular;
Exige disciplina e disposição de se preocupar antes.
Duplicação Entre Desenvolvedores
Mais difícil de detectar e manipular;
Pode passar despercebida por anos;
Encorajar comunicação ativa e freqüente entre 
desenvolvedores.
Dica 12
Facilite a reutilização.
Ortogonalidade
Termo emprestado da geometria;
Representa um tipo de independência ou desvinculação;
Duas ou mais coisas são ortogonais quando alterações em uma 
não afetam as outras;
Vantagens:
–Maior produtividade;
–Menor risco.
Diagramas de Camadas
Interface de Usuário
Acesso ao Banco de 
Dados
Mecanismo de 
Relatório
Lógica de 
Negócio
Estrutura do Aplicativo
Biblioteca C Padrão
Sistema Operacional
Dica 13
Elimine efeitos entre elementos não relacionados.
Codificando
Mantenha seu código desvinculado;
Evite dados globais;
Evite funções semelhantes;
Reversibilidade
“Nada é mais perigoso do que uma idéia quando 
ela é a única que você tem.”
Emil-Auguste Chartier, Propos sur la religion, 1983
Dica 14
Não há decisões definitivas.
Dica 15
Use projéteis luminosos para encontrar o alvo.
Vantagens
Os usuários podem ver algo funcionando antes;
Os desenvolvedores constroem uma estrutura na qual podem 
trabalhar;
Você terá uma plataforma de integração;
Você terá algo para demonstrar;
Você sentirá melhor o progresso;
Dica 16
Crie protótipos para aprender.
Dica 17
Programe em um nível próximo ao domínio do problema.
Dica 18
Estime para evitar surpresas.
Estimando
Entenda o que está sendo pedido;
Construa um modelo do sistema;
Divida o modelo em componentes;
Dê a cada parâmetro um valor;
Calcule respostas;
Acompanhe sua habilidade em estimar.
Dica 19
Reexamine o cronograma junto ao código.
As Ferramentas Básicas
Dica 20
Mantenha as informações em texto simples.
Dica 21
Use o poder dos shells de comando.
Dica 22
Use bem o seu editor.
O Que Fazer?
Quem fez alterações nessa linha de código;
Qual é a diferença entre a versão atual e da última semana?
Quantas linhas de código alteramos nessa versão?
Que arquivos foram alterados com mais freqüência?
Dica 23
Use sempre o controle de código-fonte.
Dica 24
Corrija o problema, esqueça o culpado.
Dica 25
Não entre em pânico.
Dica 26
“select”não está com defeito.
Dica 27
Não suponha – teste.
Dica 28
Aprenda uma linguagem de manipulação de texto.
Dica 29
Escreva um código que crie códigos.
Paranóia Pragmática
Dica 30
Você não conseguirá criar um software perfeito.
Dica 31
Projete com contratos.
Dica 32
Encerre antecipadamente.
Dica 33
Se não pode acontecer, use asserções para assegurar que não 
aconteça.
Dica 34
Use exceções para problemas excepcionais.
Dica 35
Acabe o que começou.
Seja Flexível
Dica 36
Reduza a vinculação entre módulos.
Dica 37
Configure, não integre.
Dica 38
Coloque as abstrações no código e os detalhes em metadados.
Dica 39
Analise o fluxo de trabalho para melhorar a concorrência.
Caipirinha
Passos:
–Descasque os limões;
–Corte em quatro partes cada limão;
–Tire os caroços e o filete branco do meio dos limões;
–Esprema alguns limões diretamente no copo com açúcar;
–Pique gelo;
–Acrescente o gelo picado e a cachaçaao copo;
–Agite bem;
–Sirva.
Concorrência
Descascar limões
Cortar limões
Remover caroços e filetes 
brancos
Picar gelo
Espremer limões
Colocar cachaça em um 
copo
Colocar açúcar em um 
copo
Colocar gelo picado em 
um copo
Agitar bem
Sirva
Dica 40
Projete usando serviços.
Dica 41
Projete sempre pensando na concorrência.
Dica 42
Separe as visualizações dos modelos.
Dica 43
Use quadros-negros para coordenar o fluxo de trabalho.
Enquanto Você Está 
Codificando
Dica 44
Não programe por coincidência.
Programando Deliberadamente
Esteja sempre consciente do que está fazendo;
Não codifique às cegas;
Aja de acordo com um plano;
Confie apenas em coisas confiáveis;
Documente suas suposições;
Não teste apenas seu código;
Priorize seu esforço;
Não seja escravo da história.
Dica 45
Estime a ordem de seus algoritmos.
Dica 46
Teste suas estimativas.
Dica 47
Refatore cedo, refatore sempre.
Quando Refatorar
Duplicação;
Projeto não ortogonal;
Conhecimento desatualizado;
Desempenho.
Dica 48
Projete para testar.
Dica 49
Teste seu software ou seus usuários testarão.
Dica 50
Não use o código de assistente que você não entender.
Antes de Começar
Dica 51
Não colete requisitos, cave-os.
Dica 52
Trabalhe com um usuário para pensar como um usuário.
Dica 53
Abstrações tem vida mais longa do que detalhes.
Dica 54
Use um glossário do projeto.
Dica 55
Não pense fora da caixa - encontre a caixa.
Desafio 1
Conectar todos os pontos do quebra-cabeça a seguir e voltar ao 
ponto inicial com apenas três linhas retas – sem tirar sua 
caneta do papel ou executar duas vezes a mesma etapa.
Resposta
Desafio 2
Você tem 10 soldados. Forme 5 filas com 4 soldados em cada 
uma.
Resposta
Dica 56
Só comece quando estiver pronto.
Dica 57 
Algumas coisas são fáceis de fazer, mas não de descrever.
Dica 58
Não seja escravo dos métodos formais.
Dica 59
Ferramentas caras não produzem software melhores.
Projetos Pragmáticos
Dica 60
Organize as equipes com base na funcionalidade.
Dica 61
Não use procedimentos manuais.
Dica 62
Teste cedo. Teste sempre. Teste automaticamente.
Dica 63
A codificação só estará concluída após todos os testes serem 
executados.
Dica 64
Use sabotadores para testar seus testes.
Dica 65
Teste a cobertura de estados e não a cobertura de código.
Dica 66
Encontre os erros apenas uma vez.
Dica 67
Trate o português simplesmente como outra linguagem de 
programação.
Dica 68
Construa a documentação no código, não acrescente como 
complemento.
Dica 69
Exceda gentilmente as expectativas de seus usuários.
Dica 70
Assine seu trabalho.
Tadeu Marinho
81 3134.5875 
tadeu.marinho@pitang.com
www.pitang.com.br