O Programador Pragmático

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.

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.

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.

Dica 20
Mantenha as informações em texto simples.

Dica 21
Use o poder dos shells de comando.

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.

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 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ça ao 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 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.

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.

Desafio 2
Você tem 10 soldados. Forme 5 filas com 4 soldados em cada
uma.

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.

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.

Tadeu Marinho
81 3134.5875
tadeu.marinho@pitang.com
www.pitang.com.br

O Programador Pragmático

Mais conteúdo relacionado

Semelhante a O Programador Pragmático (20)

Mais de Tadeu Marinho (13)

Último (19)

O Programador Pragmático