O programador Pragmático   De aprendiz      a mestre                           Edgard Davidson                           @...
Referências                      Andrew Hunt       David Thomas
!"#$#%&#($)(*+*,-*./0$#1$21$               3(04#)05$60.)(*)*(#7$0%$*2)0(#%$                /#%)#$,7(08$"#$.90$60.%#:27(5$ ...
Este livro contempla:  combater a deterioração de software  não duplicar informações  escrever código flexível, dinâmico e ...
Preocupe-se com seu trabalho       Por que passar sua vida desenvolvendo software             se não estiver interessado e...
Reflita sobre seu trabalho  Desligue o piloto automático e assuma o controle.  Critique e avalie constantemente seu trabal...
Forneça opções, não dê  desculpas  esfarrapadas  Em vez de desculpas,   forneça     opções. Não diga que não     pode ser ...
Não	 tolere	 janelas	 quebradasCorrija	 projetos	 incorretos,	 decisões	  erradas	 e	 códigos	 frágeis	 quando	 os	       ...
Seja	  um	  catalisador	  de	  mudanças     Você não pode impor mudanças às pessoas.Em vez disso, mostre a elas como o fut...
Lembre-se do cenário em larga escalaNão fique tão absorvido pelos detalhes a ponto de não ver o que                  está ...
Tome a qualidade parte dos requisitos  Envolva seus usuários na determinação dos requisitos de qualidade                  ...
2)3+41&!5%6-7&($%)1%!%$!4-&!8&(1%+(&!*%!             8#).%8+$%)1#!                 !    "#$%!#!&(%)*+,&*#!!-$!./0+1#!     ...
Analise criticamente o que você lê e ouveNão se deixe levar por fornecedores, pela mídia ou por dogmas. Analise as        ...
É o que você diz e a maneira como diz  Não	 adianta	 ter	 grandes	 idéias	 se	 elas	 não	 forem	 divulgadas	 de	 modo	 efi...
NSR	  –	  Não	  Se	  Repita     Cada	  bloco	  de	  informações	  deve	  ter	  uma	  representação	  oficial,	             ...
Facilite a reutilização   Se	  for	  fácil	  reu,lizar,	  será	  reu,lizado.	  Crie	  um	  ambiente	  que	                ...
Elimine efeitos entre     elementos não     relacionadosProjete componentes que sejam auto-suficientes, independentes e com...
Não há decisões definitivas          Nenhuma decisão é irrevogável: planeje-se para a mudança.
Crie protótipos para aprenderA criação de protótipos é uma experiência de aprendizado. Seu valor não          está no códi...
Programe em um nível próximo ao       domínio do problemaProjete e codifique na linguagem do seu usuário.
Estime	  para	  evitar	  surpresasEstime	  antes	  de	  começar.	  Você	  identificará	  possíveis	  problemas	           ...
Use controle de versãoO versionamento é a máquina de tempo de seu trabalho – ele o                      permite voltar.
Corrija o problema,esqueça o culpadoNão importa se você ou outrapessoa foi o culpado pelo bug –  ele precisará de correção...
Não suponha – teste                 Comprove suas suposições no                  ambiente real – com dados e              ...
Escreva um código que escreva códigos        Os geradores de códigos aumentam a           produtividade e ajudam a evitar ...
Programe por contratos          Use contratos para    documentar e provar que   o código não faz mais nem    menos do que ...
Use exceções para problemas excepcionais  try{  }catch(){  }catch(){  }finally{  }      As	  exceções	  podem	  sofrer	  d...
Reduza a vinculação entre módulos  Evite a vinculação escrevendo códigos “cautelosos” e aplicando a lei de Deméter
Es,me	  a	  ordem	  de	  complexidade	                     O(n)	  de	  seus	  algoritmos	     Tenha	  uma	  idéia	  de	  q...
Tenha suas estimativas A análise matemática de algoritmos não diz tudo. Tente  cronometrar seu código em seu ambiente de d...
Refatore cedo, refatore sempreDa mesma forma que você pode capinar e reorganizar um jardim,  reescreva, reorganize e recon...
Projete para testar              Comece a pensar no teste antes de                  escrever uma linha de código
Teste seu código ou seus usuários testarão  Teste incansavelmente. Não deixe que seus          usuários encontre erros par...
Não use código de wizard que você não entende      Wizards	 podem	 gerar	 muitas	 linhas	 de	 código.	 Verifique	 se	 você...
Trabalhe com usuários para  pensar como um usuário É a melhor maneira de entender como o      sistema será usado de verdade
Abstrações tem vida mais longa do que detalhes   Invista na abstração e não na implementação.     As abstrações podem sobr...
Use um glossário do projeto      Crie	  e	  mantenha	  uma	  fonte	  exclusiva	  com	  todos	  os	  termos	  e	           ...
Não pense fora da caixa – encontre              a caixa Quando diante de um problema difícil, identifique todas as    rest...
Não seja escravo de métodos           formaisNão adote cegamente qualquer técnica sem trazê-la para o contexto de suas prá...
Ferramentas caras não produzem projetos melhores         Cuidado	 com	 a	 propaganda	 dos	 fornecedores,	 com	 dogmas	 da	...
Organize	 as	 equipes	 com	 base	 na	 funcionalidade          Não separa projetista de codificadores,    testadores de mode...
Teste cedo. Teste Sempre. Teste automaticamenteTestes executados a cada construção são muito mais eficazes do que planos d...
A codificação só estará concluída    após todos os testes serem           executadosNada mais a declamar.
Use o seu conhecimento para testar seus testes      Introduza erros de propósito em uma cópia     separada da fonte para v...
Teste	  a	  cobertura	  de	  estados	  e	  não	  a	  cobertura	  do	  código                 teste	  estados	  significa:vo...
Encontre os erros apenas uma vez                  Quanto um testador humano encontrar um                  erro, essa deve ...
Construa a documentação no código, não a acrescente como                           complemento                            ...
Exceda gentilmente as expectativas de seus usuários  Tente estender as expectativas de seus usuários e então              ...
Assine	  seu	  trabalhoOs	  artesões	  da	  an,guidade	  ficavam	  orgulhosos	  em	  assinar	  seu	                      tr...
Obrigado!
O programador pragmático
Próximos SlideShares
Carregando em…5
×

O programador pragmático

7.086 visualizações

Publicada em

O Programador Pragmático se concentra no processo fundamental do desenvolvimento de software:
a partir de um requisito, produzir código funcional e de fácil manutenção que agrade aos usuários.
Sem se ater a uma tecnologia específica, esta obra aborda tópicos que vão do desenvolvimento da carreira a técnicas de projeto para manter seu código flexível e fácil de adaptar

Publicada em: Educação
1 comentário
22 gostaram
Estatísticas
Notas
  • Olá, Escrevi um livro chamado: Guia do Mestre Programador. Pensando como Pirata, evoluindo como Jedi, que acabou de ser lançado pela Casa do Código, quem quiser conferir por favor acesse o link abaixo: http://www.casadocodigo.com.br/products/livro-guia-mestre-programador
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
Sem downloads
Visualizações
Visualizações totais
7.086
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1.052
Ações
Compartilhamentos
0
Downloads
187
Comentários
1
Gostaram
22
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

O programador pragmático

  1. 1. O programador Pragmático De aprendiz a mestre Edgard Davidson @edgarddavidson
  2. 2. Referências Andrew Hunt David Thomas
  3. 3. !"#$#%&#($)(*+*,-*./0$#1$21$ 3(04#)05$60.)(*)*(#7$0%$*2)0(#%$ /#%)#$,7(08$"#$.90$60.%#:27(5$ 3(062(*(#7$6*./7/*)0%$;2#$,#(*1$ #%)*$0+(*8<$ ! !"#$%%&(()(*+",%
  4. 4. Este livro contempla: combater a deterioração de software não duplicar informações escrever código flexível, dinâmico e adaptável evitar a programação baseada no acaso blindar seu código com contratos, asserções e exceções capturar requisitos reais testar de modo incansável e eficaz agradar seus usuários montar equipes de programadores pragmáticos aumentar a precisão de seus desenvolvimentos com automação.
  5. 5. Preocupe-se com seu trabalho Por que passar sua vida desenvolvendo software se não estiver interessado em fazê-lo bem?
  6. 6. Reflita sobre seu trabalho Desligue o piloto automático e assuma o controle. Critique e avalie constantemente seu trabalho.
  7. 7. Forneça opções, não dê desculpas esfarrapadas Em vez de desculpas, forneça opções. Não diga que não pode ser feito; explique o que pode ser feito.
  8. 8. Não tolere janelas quebradasCorrija projetos incorretos, decisões erradas e códigos frágeis quando os encontrar
  9. 9. Seja  um  catalisador  de  mudanças Você não pode impor mudanças às pessoas.Em vez disso, mostre a elas como o futuro pode ser e ajude-as a participar de sua criação
  10. 10. Lembre-se do cenário em larga escalaNão fique tão absorvido pelos detalhes a ponto de não ver o que está acontecendo ao seu redor
  11. 11. Tome a qualidade parte dos requisitos Envolva seus usuários na determinação dos requisitos de qualidade do projeto.
  12. 12. 2)3+41&!5%6-7&($%)1%!%$!4-&!8&(1%+(&!*%! 8#).%8+$%)1#! ! "#$%!#!&(%)*+,&*#!!-$!./0+1#! !
  13. 13. Analise criticamente o que você lê e ouveNão se deixe levar por fornecedores, pela mídia ou por dogmas. Analise as informações em relação a si mesmo e ao seu projeto
  14. 14. É o que você diz e a maneira como diz Não adianta ter grandes idéias se elas não forem divulgadas de modo eficaz.
  15. 15. NSR  –  Não  Se  Repita Cada  bloco  de  informações  deve  ter  uma  representação  oficial,   exclusiva  e  sem  ambiguidade  dentro  de  um  sistema.
  16. 16. Facilite a reutilização Se  for  fácil  reu,lizar,  será  reu,lizado.  Crie  um  ambiente  que   apóie  a  reu,lização
  17. 17. Elimine efeitos entre elementos não relacionadosProjete componentes que sejam auto-suficientes, independentes e com uma finalidade exclusiva bem definida.
  18. 18. Não há decisões definitivas Nenhuma decisão é irrevogável: planeje-se para a mudança.
  19. 19. Crie protótipos para aprenderA criação de protótipos é uma experiência de aprendizado. Seu valor não está no código produzido, mas nas lições aprendidas.
  20. 20. Programe em um nível próximo ao domínio do problemaProjete e codifique na linguagem do seu usuário.
  21. 21. Estime  para  evitar  surpresasEstime  antes  de  começar.  Você  identificará  possíveis  problemas   logo  de  início.
  22. 22. Use controle de versãoO versionamento é a máquina de tempo de seu trabalho – ele o permite voltar.
  23. 23. Corrija o problema,esqueça o culpadoNão importa se você ou outrapessoa foi o culpado pelo bug – ele precisará de correção de qualquer forma.
  24. 24. Não suponha – teste Comprove suas suposições no ambiente real – com dados e condições reais.
  25. 25. Escreva um código que escreva códigos Os geradores de códigos aumentam a produtividade e ajudam a evitar a duplicação
  26. 26. Programe por contratos Use contratos para documentar e provar que o código não faz mais nem menos do que ele propõe fazer.
  27. 27. Use exceções para problemas excepcionais try{ }catch(){ }catch(){ }finally{ } As  exceções  podem  sofrer  de  todos  os  problemas  de   legibilidade  e  manutenção  dos  emaranhados  de  códigos   clássicos.  Guarde-­‐as  para  acontecimentos  excepcionais.  
  28. 28. Reduza a vinculação entre módulos Evite a vinculação escrevendo códigos “cautelosos” e aplicando a lei de Deméter
  29. 29. Es,me  a  ordem  de  complexidade   O(n)  de  seus  algoritmos   Tenha  uma  idéia  de  quanto  o  processo  deve  demorar  antes  de  escrever  o  código Fonte: Nívio Ziviani
  30. 30. Tenha suas estimativas A análise matemática de algoritmos não diz tudo. Tente cronometrar seu código em seu ambiente de destino.
  31. 31. Refatore cedo, refatore sempreDa mesma forma que você pode capinar e reorganizar um jardim, reescreva, reorganize e reconstrua o código quanto necessário. Ataque a raiz do problema.
  32. 32. Projete para testar Comece a pensar no teste antes de escrever uma linha de código
  33. 33. Teste seu código ou seus usuários testarão Teste incansavelmente. Não deixe que seus usuários encontre erros para você
  34. 34. Não use código de wizard que você não entende Wizards podem gerar muitas linhas de código. Verifique se você o entendeu por completo antes de introduzi-lo no seu projeto.
  35. 35. Trabalhe com usuários para pensar como um usuário É a melhor maneira de entender como o sistema será usado de verdade
  36. 36. Abstrações tem vida mais longa do que detalhes Invista na abstração e não na implementação. As abstrações podem sobreviver às diversas mudanças provenientes de diferentes implementações e novas tecnologias.
  37. 37. Use um glossário do projeto Crie  e  mantenha  uma  fonte  exclusiva  com  todos  os  termos  e   vocabulário  específicos  de  um  projeto
  38. 38. Não pense fora da caixa – encontre a caixa Quando diante de um problema difícil, identifique todas as restrições reais. Faça a si próprio a pergunta: “Isso precisa ser feito?” De fato, precisa ser feito?
  39. 39. Não seja escravo de métodos formaisNão adote cegamente qualquer técnica sem trazê-la para o contexto de suas práticas e capacidades de desenvolvimento
  40. 40. Ferramentas caras não produzem projetos melhores Cuidado com a propaganda dos fornecedores, com dogmas da indústria e com o apelo da etiqueta de preço. Julgue as ferramentas por seu mérito
  41. 41. Organize as equipes com base na funcionalidade Não separa projetista de codificadores, testadores de modeladores de dados. Construa equipes como constrói o código.
  42. 42. Teste cedo. Teste Sempre. Teste automaticamenteTestes executados a cada construção são muito mais eficazes do que planos de teste que ficam aguardando para ser executados.
  43. 43. A codificação só estará concluída após todos os testes serem executadosNada mais a declamar.
  44. 44. Use o seu conhecimento para testar seus testes Introduza erros de propósito em uma cópia separada da fonte para verificar se os testes irão capturá-los.
  45. 45. Teste  a  cobertura  de  estados  e  não  a  cobertura  do  código teste  estados  significa:vos  do  programa.   Iden,fique  e   Testar  apenas  linhas  de  código  não  é  suficiente.
  46. 46. Encontre os erros apenas uma vez Quanto um testador humano encontrar um erro, essa deve ser a última vez que um testador humano o encontrará. Testes automatizados devem procurá-lo desse momento em diante.
  47. 47. Construa a documentação no código, não a acrescente como complemento Documentação criada separadamente do código tem menos probabilidade de estar correta e atualizadaNarrative:In order to calculate BMI with easeAs a doctorI want to have BMI Calculator applicationScenario: Simple BMI calculator validationGiven a body mass index calculatorWhen a patients is with mass 77 kg and height 1.75 mThen patients body mass index is 25.14285659790039
  48. 48. Exceda gentilmente as expectativas de seus usuários Tente estender as expectativas de seus usuários e então entregue apenas um pouco mais
  49. 49. Assine  seu  trabalhoOs  artesões  da  an,guidade  ficavam  orgulhosos  em  assinar  seu   trabalho.  Você  também  deve  ficar
  50. 50. Obrigado!

×