Baixado 12 vezes
![1970...
[...]ironicamente, Royce
defendia um abordagem
iterativa para o
desenvolvimento de
software e nem mesmo
usou o termo cascata[...]](https://image.slidesharecdn.com/profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013-131017142657-phpapp01/85/Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013-111-320.jpg)
![[...]Royce originalmente
descreve o que é hoje
conhecido como o
modelo em cascata como
um exemplo de um
método que ele
argumentava ser um risco
e um convite para
falhas[...]](https://image.slidesharecdn.com/profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013-131017142657-phpapp01/85/Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013-112-320.jpg)
Carregado porGabriel Rubens
Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013
O documento discute práticas para melhoria contínua de programadores, incluindo refatoração, testes automatizados, e comunicação com usuários. Ele enfatiza uma abordagem pragmática e iterativa ao desenvolvimento de software.
Mais conteúdo relacionado
Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013
- 1. Profissão Programador: Práticas para MelhoriaContínua Unimonte - Outubro 2013 Agatha Lisboa Gabriel Rubens agatha.lisboa@gmail.com / @gabrielrubenss
- 2.
- 3.
- 4. O foco dapalestra é ajudar programadores a se tornarem melhores
- 5. Não importa sevocê trabalha sozinho, em equipe ou com muitos clientes
- 6. Programar é umaarte, e como programador você é um artesão
- 7. Transformar requisitos vagos em umprograma. Documentar seu trabalho
- 9.
- 10.
- 11. Linguagens de Programação pra todasas situações
- 12.
- 13. Não existe balade prata!
- 14. Não há umasolução que resolva todos os problemas.
- 15.
- 16. Dica :) Reflita sobreseu trabalho.
- 17.
- 19.
- 20.
- 21. O gato comeumeu código-fonte
- 22.
- 23. Dica :) Forneça soluções enão desculpas esfarrapadas.
- 24.
- 25.
- 26.
- 27. Dica :) Não tolerejanelas quebradas
- 28.
- 29. Envolva os usuários natomada de decisões
- 30. Dica :) Torne qualidade partedos requisitos
- 31. Software funcionando é a medidaprimária de progresso
- 32.
- 33. Ciência + arte+ trabalho manual
- 34.
- 36.
- 37.
- 38. Semelhante ao gerenciamento de umacarteira de investimentos
- 39.
- 40. Dica :) Invista regularmente em suacarteira de conhecimentos
- 41. Dica :) Analise criticamente o quevocê vê e ouve
- 42.
- 44. Conheça o quevai dizer
- 45. Conheça pra quem vaidizer
- 46.
- 47.
- 48. Dica :) Não éo que você diz e a maneira como diz
- 49.
- 50.
- 51.
- 52. Dica :) NSR -Não Se Repita DRY - Don't Repeat Yourself
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.
- 59. Dica :) Elimine efeitos entreelementos não relacionados
- 60.
- 61. Dica :) Não hádecisões definitivas
- 62.
- 63.
- 64. Dica :) Use projéteis luminosospara encontrar seu alvo
- 65. Programe Igual ao Domíniodo Usuário
- 66. Dica :) Programe emum nível próximo ao domínio do problema (usuário)
- 69.
- 70. Dica :) Estime paraevitar surpresas
- 71. Que nível de exatidãoé suficientemente exato?
- 72. Entenda o queestá sendo pedido
- 73.
- 74. Dica :) Reexamine o cronogramajunto ao código
- 75. O que dizerquando lhe pedirem uma estimativa?
- 76.
- 77.
- 78.
- 79. A melhor formade se comunicar é visualmente
- 84.
- 85.
- 87. Programar é uma tarefaque envolve muita habilidade e raciocínio
- 88. Quando você não prestaAtenção no que está fazendo! (mesmo que você seja muito bom)
- 89.
- 90. Refatorar é melhorar umcódigo existente sem alterar o seu funcionamento
- 91.
- 92.
- 94. -Código duplicado -Método longo -Classegrande -Lista de parâmetros longa -Má indentação E muito mais!
- 95.
- 96. Código Que Seja Fácilde Testar
- 97.
- 98. Devemos ter o hábitode testar unitariamente nosso software (procure o xUnit da sua linguagem favorita)
- 99. Testando a Integração entreos Componentes
- 100. Testando a Carga queseu Sistema Suporta
- 101. Dica :) Teste seu softwareou seus usuários testarão
- 103.
- 104. Existem várias camadas deteste. Aprenda para saber quais são necessárias para seu problema
- 106.
- 107.
- 108. Dica :) Não useum código de assistente que você não entender
- 109.
- 110.
- 111. 1970... [...]ironicamente, Royce defendia umabordagem iterativa para o desenvolvimento de software e nem mesmo usou o termo cascata[...]
- 112. [...]Royce originalmente descreve oque é hoje conhecido como o modelo em cascata como um exemplo de um método que ele argumentava ser um risco e um convite para falhas[...]
- 115. RUP você pegatoda a documentação no início.
- 116. RUP você pegatoda a documentação no início. Agile você não documenta nada.
- 117. RUP você pegatoda a documentação no início. Agile você não documenta nada. Será mesmo!?
- 118. P.: RUP vocêpega toda a documentação no início? R.: Isso é cascata! P.: Agile você não documenta nada. R.: Não há isso em lugar nenhum!
- 119. Dica :) Trabalhe com usuáriopara pensar como um usuário
- 120. Dica :) Abstração tem vidamais longa do que detalhes
- 121.
- 122. Uma visão geralde como ser Pragmático
- 123. Uma visão geralde como ser uma equipe Pragmático
- 124.
- 125.
- 126. Dica :) Não serepita
- 127.
- 128. Dica :) Saiba quando pararde adicionar retoques
- 129. Dica :) Teste! O melhoramigo do Programador
- 130. Dica :) Seja um catalizadorde mudanças
- 131.
- 132. Dica :) Lembre-se do cenárioem larga escala
- 133.
- 135.
- 136.
- 137.
- 140.
- 141. Pra quem sótem martelo todo problema é um prego!
- 142. Profissão Programador: Práticas para MelhoriaContínua Unimonte - Outubro 2013 Agatha Lisboa Gabriel Rubens agatha.lisboa@gmail.com / @gabrielrubenss