Qualidade no desenvolvimento de softwre

222 visualizações

Publicada em

Dicas para que nós desenvolvedores de software possamos a cada dia sermos melhores profissionais de desenvolvimento de software.

Publicada em: Software
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
222
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
4
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • 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á ....
  • Qualidade no desenvolvimento de softwre

    1. 1. Você é um desenvolvedor de software acima da média? Qualidade no desenvolvimento de software
    2. 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. 3. Você se considera um desenvolvedor de software ACIMA da média?
    4. 4. Afinal, programar é fácil !!!!!!
    5. 5. Mas desenvolver um software com qualidade, que seja funcional e que possa evoluir com sustentabilidade ....
    6. 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. 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. 8. Mas se durante a construção quisermos adicionar um andar para garagem?
    9. 9. Ou depois de pronto o cliente: “gostei, mas não dava para mover 20 metros mais para o lado?”
    10. 10. No desenvolvimento de software mudanças são naturais em qualquer etapa !
    11. 11. Qual o custo para construir outro edifício igual ao lado?
    12. 12. E para copiar o software, qual o custo?
    13. 13. Ok, mas e se perdêssemos o código fonte? Seria o mesmo custo?
    14. 14. Desenvolvimento de software é aprendizado !!!!
    15. 15. Time de desenvolvimento de software ao fechar 1 ano em um projeto único !
    16. 16. O time apenas se preocupou em PROGRAMAR !!!
    17. 17. Afinal, programar é fácil !!!!!!
    18. 18. Mas ao final do segundo ano ....
    19. 19. Vamos contratar mais programadores, afinal o problema é produtividade !
    20. 20. Agora temos uma bomba prestes e explodir
    21. 21. Ao contrário do esperado ...
    22. 22. De quem é a culpa?
    23. 23. Ou seja a cozinha ficou bagunçada demais !
    24. 24. Vamos refazer tudo ... Então time novo!
    25. 25. E o time antigo?
    26. 26. Mas o que realmente houve?
    27. 27. O time perdeu produtividade no momento em que abriu mão da qualidade do código gerado?
    28. 28. Eles são rápidos porque abrem mão da qualidade?
    29. 29. Qual grau de qualidade do seu código?
    30. 30. 0% = Código escrito por MIL MACACOS
    31. 31. 100% = Código impecável
    32. 32. Times altamente produtivos são formados por pessoas que querem aprender constantemente!
    33. 33. REFACTORING !!!!!! Alterar o código em funcionamento para torna-lo mais legível, eficiente e elegante.
    34. 34. Mas antes, testes unitários ......
    35. 35. Por exemplo ...
    36. 36. Primeiro refactoring: Nome de variáveis
    37. 37. Segundo refactoring: Extract method
    38. 38. Aplicando Design Pattern Builder
    39. 39. 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
    40. 40. Quais as características de profissionais acima da média?
    41. 41. Iniciativa
    42. 42. Cooperação e não competição
    43. 43. Ensina ....
    44. 44. Gosta de compartilhar conhecimento
    45. 45. São apaixonados pelo que fazem
    46. 46. Produtividade != Esforço
    47. 47. São focados
    48. 48. São adaptáveis
    49. 49. O time deveria se perguntar frequentemente ....
    50. 50. Estamos amadurecendo?
    51. 51. Estamos desenvolvendo software com mais qualidade e tecnologias melhores?
    52. 52. Dominamos ou estamos no caminho de dominar as ferramentas e tecnologia que utilizamos?
    53. 53. E o mais importante ...
    54. 54. Faça chuva...
    55. 55. Faça sol...
    56. 56. Esteja com azar ...
    57. 57. Esteja com sorte ....
    58. 58. De um passo em direção ao seu objetivo !
    59. 59. Agora, se você está com sorte e tem sol .....
    60. 60. Porque no final, você se considera um desenvolvedor de software ACIMA da média?
    61. 61. 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

    ×