Programação de Elite - Requisito dado é código implementado
Transferir como PPTX, PDF1 gostou447 visualizações
O documento discute tópicos relacionados ao desenvolvimento de software, incluindo controle de versão, técnicas e padrões de desenvolvimento, e testes unitários. Ele enfatiza a importância de seguir boas práticas como orientação a objetos, refatoração, padrões de projeto e princípios SOLID para escrever código extensível e de fácil manutenção.
Programação de Elite - Requisito dado é código implementado
- 2. Agenda • Controle de Versão • Desenvolvimento – Técnicas e padrões • Testes Unitários – Introdução ao DUnitX
- 3. • Não sentimos falta do que não conhecemos • Não sentimos falta do que não usamos • Os corruptos e os fracos são sempre os primeiros a cair. • Aqui não tem lugar para fanfarrão. • Aqui não tem lugar para programador corrupto.
- 4. Controle de Versão • Prezar pela sua segurança!
- 5. Controle de Versão • Subversion • Git • Mercurial
- 6. Controle de Versão Servidores gratuitos: • bitbucket.org • assembla.com
- 7. Ferramenta de comparação • O Beyond Compare Lite 4 • Integração com ferramentas externas (Environment Options > Difference Viewer)
- 8. “Quando um programador entra em um código legado para refatorar, não adianta achar que vai dar para apagar tudo e refazer do Zero. Existe muito código inocente, que foi escrito corretamente e não merece ser apagado.” “O Programador de Elite não entra em código fonte apagando tudo, ele entra com estratégia, progride de bloco em bloco, método por método.”
- 9. Desenvolvimento • Orientação a Objetos • Quais os 4 paradigmas da orientação de objetos?
- 10. Desenvolvimento • Abstração • Herança • Encapsulamento • Polimorfismo
- 11. Desenvolvimento • Refatoração • Padrões de Projeto • S.O.L.I.D. • Lei de Demeter, DRY • Anti-Patterns
- 12. S.O.L.I.D • Os princípios SOLID são cinco princípios básicos de programação e design orientados a objetos, introduzidos por Uncle Bob no início de 2000. • Aplicados em conjunto, podem diferenciar um desenvolvedor, tornando-o capaz de escrever um código extensível, coeso e de fácil manutenção.
- 13. Princípio da responsabilidade única • Uma classe deve ter apenas um único motivo para mudar.
- 14. Principio da inversão da dependência • "Código contra abstrações não implementadas”. • "Sempre dependa de uma interface, não uma implementação.” • "Módulos de alto nível não devem depender de módulos de baixo nível, ambos devem depender de abstrações. Abstrações não devem depender de detalhes. Os detalhes devem depender abstrações”.
- 16. Perguntas?