Desenvolvimento de software com qualidade
•Télécharger en tant que PPTX, PDF•
1 j'aime•315 vues
O documento discute a importância da qualidade no desenvolvimento de software, comparando-o com a construção civil. Ele argumenta que desenvolvedores acima da média se concentram em melhorar continuamente suas habilidades e produzir código limpo e sustentável através de práticas como refatoração e testes unitários. O documento também lista características desejáveis como iniciativa, cooperação e compartilhamento de conhecimento.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Desenvolvimento de software com qualidade
Similaire à Desenvolvimento de software com qualidade (20)
Desenvolvimento de software com qualidade
- 1. Você é um desenvolvedor de software acima da média? Qualidade no desenvolvimento de software
- 2. Sobre ▪ Sobre o tema: ▪ Examinar o impacto de desenvolver software sem qualidade de código, bem como, o reflexo na carreira de um desenvolvedor de software. ▪ Sobre o palestrante: ▪ Gabriel Schmitt Kohlrausch, apaixonado por desenvolvimento de software. Buscando constantemente aprender boas práticas para a construção de software com qualidade, agilidade e sustentabilidade. Nerd, Gamer e praticante de paintball. ▪ gabriel@society.com.br | http://stiblog.azurewebsites.net/
- 3. Você se considera um desenvolvedor de software ACIMA da média?
- 4. Afinal, programar é fácil !!!!!!
- 5. Mas desenvolver um software com qualidade, que seja funcional e que possa evoluir com sustentabilidade ....
- 6. Desenvolvimento de software é parecido com a construção civil? Planta baixa (engenharia) Projeto (Cronograma) Construção Entrega Manutenção Processo de construção civil
- 7. Desenvolvimento de software é parecido com a construção civil? Requisitos (engenharia) Projeto (Cronograma) Desevolvimento (construção) Entrega Manutenção Processo de desenvolvimento de software
- 8. Mas se durante a construção quisermos adicionar um andar para garagem?
- 9. Ou depois de pronto o cliente: “gostei, mas não dava para mover 20 metros mais para o lado?”
- 10. No desenvolvimento de software mudanças são naturais em qualquer etapa !
- 11. Qual o custo para construir outro edifício igual ao lado?
- 12. E para copiar o software, qual o custo?
- 13. Ok, mas e se perdêssemos o código fonte? Seria o mesmo custo?
- 14. Desenvolvimento de software é aprendizado !!!!
- 15. Time de desenvolvimento de software ao fechar 1 ano em um projeto único !
- 16. O time apenas se preocupou em PROGRAMAR !!!
- 17. Afinal, programar é fácil !!!!!!
- 18. Mas ao final do segundo ano ....
- 19. Vamos contratar mais programadores, afinal o problema é produtividade !
- 20. Agora temos uma bomba prestes e explodir
- 21. Ao contrário do esperado ...
- 22. De quem é a culpa?
- 23. Ou seja a cozinha ficou bagunçada demais !
- 24. Vamos refazer tudo ... Então time novo!
- 25. E o time antigo?
- 26. Mas o que realmente houve?
- 27. O time perdeu produtividade no momento em que abriu mão da qualidade do código gerado?
- 28. Eles são rápidos porque abrem mão da qualidade?
- 29. Qual grau de qualidade do seu código?
- 30. 0% = Código escrito por MIL MACACOS
- 31. 100% = Código impecável
- 32. Times altamente produtivos são formados por pessoas que querem aprender constantemente!
- 33. REFACTORING !!!!!! Alterar o código em funcionamento para torna-lo mais legível, eficiente e elegante.
- 34. Mas antes, testes unitários ......
- 35. Por exemplo ...
- 39. Primeiro refactoring: Nome de variáveis
- 40. Segundo refactoring: Extract method
- 41. Aplicando Design Pattern Builder
- 42. Código limpo, legível e sustentável ... DDD (Domain Driven Design) TDD (Test Driven Design) S.O.L.I.D SOA (Service Oriented Architecture) AOP (Aspect Oriented Programming) Desing Patterns Architectural Patterns Agile Principles
- 43. Quais as características de profissionais acima da média?
- 44. Iniciativa
- 45. Cooperação e não competição
- 46. Ensina ....
- 48. São apaixonados pelo que fazem
- 50. São focados
- 51. São adaptáveis
- 52. O time deveria se perguntar frequentemente ....
- 54. Estamos desenvolvendo software com mais qualidade e tecnologias melhores?
- 55. Dominamos ou estamos no caminho de dominar as ferramentas e tecnologia que utilizamos?
- 56. E o mais importante ...
- 57. Faça chuva...
- 58. Faça sol...
- 59. Esteja com azar ...
- 60. Esteja com sorte ....
- 61. De um passo em direção ao seu objetivo !
- 62. Agora, se você está com sorte e tem sol .....
- 63. Porque no final, você se considera um desenvolvedor de software ACIMA da média?
- 64. Referências • The Art of Unit Testing, Roy Osherove • Agile Development, James Shore & Chromatic • Test-Driven Development, Kent Beck • Software Architecture in Pratice, Len Bass & Paul Clements & Rick Kazman • Clean Code, Robert C. Martin • Agile, André Farias Gomes • http://pt.slideshare.net/bluesoftbr/construindo-uma-cultura-de-aprendizagem-mar-de-agilidade-salvador-2011 • http://pt.slideshare.net/lcobucci/refactoring-like-a-boss-8-solisc
Notes de l'éditeur
- Considerar que é relativamente fácil gerar código. Aprender uma linguagem é fácil. Escrever um código para resolver um problema é fácil.
- Porém desenvolver um software que possa evoluir sem problemas para o time, sem perda de qualidade é bem diferente e muito mais complicado.
- Para entendermos melhor essa afirmação vamos pensar juntos o que é desenvolvimento de software? É possível comparar o processo de desenvolvimento de software com o processo de construção civil?
- Afinal de contas temos as mesmas etapas, planejamento, arquitetura, construção, entrega e depois manutenção. Porém existem dois pontos importantes que fazem toda a diferença.
- E se quisermos uma piscina na cobertura? E se for necessário mais um andar?
- Em contra partida é perfeitamente natural que um software sofra alterações durante seu desenvolvimento.
- Outra grande diferença....
- O custo de desenvolvimento seria igual ao da primeira vez? Não seria mais rápido desenvolver e ainda por cima ele não seria melhor que a primeira versão?
- No início de um projeto, o cliente e nós, não sabemos exatamente o que será o software. Porem ao longo do tempo ambos vão aprendendo e construindo um produto alinhado as necessidades e este conhecimento adquirido não é perdido.
- Vamos além, imaginem um time de desenvolvedores de uma startup. Sua única preocupação é um único projeto. Após um ano de projeto é feito uma retrospectiva do ano e constatou-se que o índice de atraso nas entregas foi baixo, o cliente está satisfeito e ainda por cima percebe-se que o software evoluiu muito, mas ainda falta funcionalidades a serem desenvolvidas.
- Ao final do segundo ano é realizada a mesma retrospectiva e constatou-se que o índice de atraso nas entregas aumentou, consequentemente o índice de satisfação do cliente diminuiu e percebeu-se que foram desenvolvidas poucas funcionalidades e muitas correções
- Os diretores da empresa, ao olharem os números, percebem que existe um problema de produtividade, afinal foi entregue muito menos do que se planejou. Mediante a pressão que o cliente coloca a empresa resolve contratar mais programadores, afinal de contas temos um problema de produtividade.
- apesar de termos uma leve impressão de aumento de produtividade, percebe-se não é verdade e o que estava confuso ficou pior ainda.
- Mediante ao CAOS estabelecido, o time e a direção da empresa realizam uma reflexão mais profunda e encontra-se um culpado: Código Legado. O time aponta que está cada vez mais difícil de desenvolver algo em meio ao código existente, que não é possível alterar o código que outro programador criou pois não o código não é compreensível e que uma alteração no código cria problemas em outros pontos do software que ninguém prevê.
- Neste momento a reflexão feita pelo time indica, metaforicamente, que a cozinha ficou bagunçada demais para trabalhar e o time perdeu produtividade pois cada vez fica mais difícil alterar o software no meio da desorganização que o código está
- Percebendo-se que não vai ser possível vencer o CAOS estabelecido, pelo código legado, surge uma ideia: Vamos refazer tudo! Contrata-se desenvolvedores especializados, um dream team, para fazer um novo software
- e os programadores antigos trabalham no legado. Resultado quando menos percebe-se acabou o dinheiro da empresa!
- Analisando o cenário descrito, será que o grande culpado foi o código legado? O que realmente houve? Desenvolvimento de software não é aprendizado? Porque o time não evoluiu e consequentemente o código não evoluiu?
- Será que na verdade o time deixou de ser produtivo porque não adotou certos padrões de qualidade no código?
- Comparando com uma equipe de F1 no momento de pitstop, a equipe é rápida porque não tem qualidade? Ou são rápidos porque tem qualidade? Ainda comparando, e se fossemos um lenhador que recebe um machado novo, no início da sua carreira, poderíamos afirmar que teríamos uma produtividade muito alta. Porém se nunca preocupássemos em afiar o machado chegaríamos a um ponto de que por mais talento e experiência adquiridos estaríamos cortando arvores com um taco e não um machado.
- Na verdade o código é o resultado do trabalho de um desenvolvedor de software, assim poderíamos dar uma nota para o nosso código!
- Acontece que, precisamos descobrir qual grau de qualidade conseguimos ser mais produtivos, pois se ficar buscando a perfeição talvez se perca produtividade também. Então como podemos constantemente melhorar nossa qualidade e consequentemente nossa produtividade? Como podemos ser melhores programadores?
- Para responder essas perguntas, relembrem-se que desenvolvimento de software é aprendizado então times altamente PRODUTIVOS são formados por pessoas que querem APRENDER constantemente!
- Devemos estar sempre apreendendo e melhorando nossa técnica de programação e para isso precisamos constantemente refatorar nosso código! Ou seja precisamos constantemente alterar um código que está em funcionamento para torna-lo mais legível, eficiente e elegante. Mas para fazermos isso precisamos garantir que o código permaneça funcionando, não podemos modificar o comportamento mas sim sua estrutura
- E neste cenário é impossível realizar re-fatoramento sem utilizar testes unitários. Escrever testes que garantam o comportamento unitário do nosso código é fundamental para a evolução de um bom código. Além de testes devemos estar de olhos abertos para a qualidade do código que escrevemos, evitando bad small’s no código e por consequência criando dívida técnica.
- Qual a finalidade do código? Está bem escrito? É fácil entender as coisas?
- Há agora melhorou um pouco mais ainda assim ... Fica complicado de ler! Comentários?
- Números mágicos, métodos longos, nomes ruins ......
- Refatorar ......
- Mas muito além de refactoring um código limpo implica em diversas outras boas práticas e técnicas devem ser aplicadas pelo programador, entre elas TDD, DDD, Princípios SOLID para orientação a objetos, padrões de projeto, padrões de arquitetura de software, princípios de engenharia de software e muito conhecimento sobre o negócio da sua aplicação. Ou seja, código limpo, legível e sustentável está ligado com muitas outras técnicas que o programador deve dominar
- Portanto um profissional acima da média, deve ter
- deve ter iniciativa (rafatorar),
- código coletivo
- não da a resposta, faz a pergunta (coaching).
- , aprende para compartilhar (não enterra o ouro),
- busca a excelência
- é focado (Pomodoro)
- Assim podemos concluir que desenvolvimento de software é aprendizado e assim devemos estar constantemente APRENDENDO coisas novas. Diariamente deveríamos nos perguntar
- E para evoluirmos como profissionais precisamos traçar um objetivo para nossas carreiras
- Porque assim você sempre estará ....