O documento discute práticas e filosofias para programadores, enfatizando a importância de qualidade, automação, testes rigorosos e colaboração com os usuários. Ele aborda temas como a manutenção de código, a análise crítica de técnicas e ferramentas, e a necessidade de adaptar práticas às realidades do projeto. O autor incentiva a reflexão sobre o trabalho de programação e a busca contínua pela melhoria e inovação.

1. O programador Pragmático
De aprendiz
a mestre
Edgard Davidson
@edgarddavidson

2. Referências
Andrew Hunt
David Thomas

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. 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. Preocupe-se com seu trabalho
Por que passar sua vida desenvolvendo software
se não estiver interessado em fazê-lo bem?

6. Reflita sobre seu trabalho
Desligue o piloto automático e assuma o controle.
Critique e avalie constantemente seu trabalho.

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. Não tolere janelas quebradas
Corrija projetos incorretos, decisões
erradas e códigos frágeis quando os
encontrar

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. Lembre-se do cenário em larga escala
Não fique tão absorvido pelos detalhes a ponto de não ver o que
está acontecendo ao seu redor

11. Tome a qualidade parte dos requisitos
Envolva seus usuários na determinação dos requisitos de qualidade
do projeto.

12. 2)3+41&!5%6-7&($%)1%!%$!4-&!8&(1%+(&!*%!
8#).%8+$%)1#!
!
"#$%!#!&'(%)*+,&*#!!-$!./0+1#!
!

13. Analise criticamente o que você lê e ouve
Nã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. É 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. 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. Facilite a reutilização
Se
for
fácil
reu,lizar,
será
reu,lizado.
Crie
um
ambiente
que
apóie
a
reu,lização

17. Elimine efeitos entre
elementos não
relacionados
Projete componentes que sejam auto-
suficientes, independentes e com uma
finalidade exclusiva bem definida.

18. Não há decisões definitivas
Nenhuma decisão é irrevogável: planeje-se para a mudança.

19. Crie protótipos para aprender
A 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. Programe em um nível próximo ao
domínio do problema
Projete e codifique na linguagem do seu usuário.

21. Estime
para
evitar
surpresas
Estime
antes
de
começar.
Você
identificará
possíveis
problemas
logo
de
início.

22. Use controle de versão
O versionamento é a máquina de tempo de seu trabalho – ele o
permite voltar.

23. Corrija o problema,
esqueça o culpado
Não importa se você ou outra
pessoa foi o culpado pelo bug –
ele precisará de correção de
qualquer forma.

24. Não suponha – teste
Comprove suas suposições no
ambiente real – com dados e
condições reais.

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. 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. 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. Reduza a vinculação entre módulos
Evite a vinculação escrevendo códigos
“cautelosos” e aplicando a lei de Deméter

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. 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. Refatore cedo, refatore sempre
Da 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. Projete para testar
Comece a pensar no teste antes de
escrever uma linha de código

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. 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. Trabalhe com usuários para
pensar como um usuário
É a melhor maneira de entender como o
sistema será usado de verdade

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. 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. 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. Não seja escravo de métodos
formais
Não adote cegamente qualquer técnica sem
trazê-la para o contexto de suas práticas e
capacidades de desenvolvimento

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. 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. Teste cedo. Teste Sempre. Teste automaticamente
Testes executados a cada construção são muito mais eficazes do
que planos de teste que ficam aguardando para ser executados.

43. A codificação só estará concluída
após todos os testes serem
executados
Nada mais a declamar.

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. 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. 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. 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
atualizada
Narrative:
In order to calculate BMI with ease
As a doctor
I want to have BMI Calculator application
Scenario: Simple BMI calculator validation
Given a body mass index calculator
When a patient's is with mass 77 kg and height 1.75 m
Then patient's body mass index is 25.14285659790039

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. Assine
seu
trabalho
Os
artesões
da
an,guidade
ficavam
orgulhosos
em
assinar
seu
trabalho.
Você
também
deve
ficar

51. Obrigado!