Engenharia de software

119 visualizações

Publicada em

Um pouco sobre tipos de processos ágéis

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

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

Nenhuma nota no slide

Engenharia de software

  1. 1. Reconstrução e contínua integração de software Pagando seus débitos técnicos e criando uma produção de pronta entrega
  2. 2. Reconstrução de código ❖ Devemos enxergar a reconstrução de código como uma conta de uma casa ❖ Sempre devemos estar em dia ❖ Reconstrução seria a realização de pequenas modificações no código, sem mexer na lógica do software ❖ Não adicionamos novos recursos ou fixamos bugs
  3. 3. Reconstrução de código Imagem 13.2
  4. 4. ❖ A reconstrução deve ocorrer desde o início do projeto ❖ Para que a mudança sempre seja menos trabalhosa ❖ Diminuição do custo de mudança Reconstrução de código
  5. 5. Reconstrução de código ❖ Se o programador sempre tiver técnicos débitos no seu código ❖ Significa que ele sempre estar tentando inovar ❖ Acumulação de débitos gera muitos problemas
  6. 6. Pagamento de débito de código Princípio Ágil ❖ Atenção contínua a excelência técnica e uma boa melhora ágil no design Imagem 13.3
  7. 7. Reconstrução consistente e contínua ❖ Trabalhar duro e receber suas recompensas ❖ Reconstrução agressiva significa que o programador a deixou para o final da iteração ❖ Deve-se reconstruir o código diariamente ❖ Quando a reconstrução e feita constantemente é quase impossível de se perceber a diferença
  8. 8. Reconstrução consistente e contínua Imagem 13.3.1
  9. 9. Reconstrução consistente e contínua Imagem 13.3.2
  10. 10. Reconstrução consistente e contínua ❖ Com Apenas esse três passos de reconstrução: 1. Renomeação de variáveis e métodos 2. Deixar variáveis na mesma linha (no caso de métodos booleanos) 3. Extrair métodos (deixar os passos do método mais visíveis) http://www.greenfoot.org/doc/tut-3
  11. 11. Reconstrução consistente e contínua ❖ Esses três passos são importantes para eventuais emergências que a equipe possa ter, como consertar bugs, e fazer mudanças críticas ❖ Observe sua situação, e veja o que precisa ser feito,faça agora o que você acha que pode lhe causar problemas futuros, caso deixe para fazer depois
  12. 12. Integração contínua: prontidão no processo de produção ❖ Criação de uma cultura de uma produção que se encontra em prontidão e ser ter a capacidade de demonstrar nosso produto para qualquer pessoa, a qualquer hora, em qualquer lugar.
  13. 13. Integração contínua: prontidão no processo de produção ❖ Em uma equipe que trabalha o conceito de prontidão no processo de prontidão podemos observar que: 1. A equipe possui um repositório único para o código fonte, onde todos podem alterar o código, sem interferir nas mudanças dos outros membros 2. As mudanças são integradas ao longo de cada dia, para que todos da equipe sabiam o que acontece no sistema
  14. 14. Integração contínua: cultura de produção de prontidão ❖ Desenvolver software se faz da mesma forma em todo lugar, quanto mais o programador demorar para reconstruir o software, mais difícil será fazer manutenção do mesmo
  15. 15. Como isso funciona ? ❖ Para implementar integração contínua ao código, sáo necessários alguns passos: 1. Um repositório para o código 2. Um processo de check-in 3. Um processo de teste automatizado 4. Boa vontade para trabalhar com pequenas partes do projeto por vez
  16. 16. Repositório de código ❖ Possuir um único local para todos da equipe alocarem o código e editarem Imagem 15.3
  17. 17. Processo automatizado de check-in do código Imagem 15.5
  18. 18. Processo automatizado de check-in do código ❖ Podemos conceituar o processo automatizado de check-in como sendo a elaboração e realização de diversos tipos de teste contra o código em questão, para a retirada de todos os erros visíveis pelos stakeholders.
  19. 19. Processo automatizado de check-in do código ❖ Para um processo automatizado de check-in de um código é necessários: 1. Utilizar a última versão do código, em seu repositório 2. Fazer alterações 3. Rodar testes até eliminar os erros visualizados 4. Adquirir novamente a última versão do código, em seu repositório 5. Realizar novos testes para remover possíveis novos problemas 6. Finalizar processo de check-in
  20. 20. Boas e más práticas no processo de check- in do código Imagem 15.5.1
  21. 21. Boas práticas no processo de check-in do código 1. Checar por versões recentes do código em seu repositório 2. Rodar todos os testes 3. Fazer check-ins regularmente 4. Deixar como prioridade códigos em que os testes não foram realizados com sucesso
  22. 22. Más práticas no processo de check-in do código 1. Deixar o código com mais problemas depois de ter rodado os testes 2. Checar códigos com problemas 3. Comentar códigos que já não são mais utilizados
  23. 23. Criação de um teste automatizado ❖ “A chave para qualquer construção(código) automatizada - quanto menos envolvimento humano,melhor.” ❖ Muitas linguagens atualmente possuem seus frameworks automatizados
  24. 24. Criação de um teste automatizado Imagem 15.6
  25. 25. Criação de um teste automatizado ❖ Esse processo consiste em 4 passos simples: 1. Cada membro da equipe realiza modificações no código e colocam no mesmo repositório 2. O sistema verifica as modificações de cada membro 3. Se caso houver algum conflito de alteração, ou se determinada alteração pode gerar alguma outro erro
  26. 26. Criação de um teste automatizado 4. O sistema avisa as membro para que os membros decidam qual modificação ficará, ou modificar novamente o código para retirar o erro que foi inserido
  27. 27. E se o programador não tiver permissão para aplicar métodos ágeis ? Imagem 15.8
  28. 28. E se o programador não tiver permissão para aplicar métodos ágeis ? ❖ Ao final se torna tudo questão de escolha ❖ Ninguém pode fazer você parar de produzir software de alta qualidade ❖ Não fale para outra pessoa o que fazer ❖ Aceita que outras pessoas não estarão com você para lhe ajudar ❖ Apenas faça o que tem que ser feito
  29. 29. Não se preocupe em se tornar ágil ❖ Ser ágil é uma jornada, não um destino ❖ Então você nunca seja realmente a agilidade ❖ E não esqueça que não é o fato de ser você ser ágil ou não, mas você produzir produtos de qualidade
  30. 30. Referências The Agile Samurai: How masters deliver great softwares,Rasmusson Jonathan,Susannah Davidson Pfalzer. 13.2 The Agile Samurai: How masters deliver great softwares,Rasmusson Jonathan,Susannah Davidson Pfalzer, p.215. 13.3.1 The Agile Samurai: How masters deliver great softwares,Rasmusson Jonathan,Susannah Davidson Pfalzer, p.218.
  31. 31. Referências 13.3.2 The Agile Samurai: How masters deliver great softwares,Rasmusson Jonathan,Susannah Davidson Pfalzer, p.221. 15.3 The Agile Samurai: How masters deliver great softwares,Rasmusson Jonathan,Susannah Davidson Pfalzer, p.239. 15.5 The Agile Samurai: How masters deliver great softwares,Rasmusson Jonathan,Susannah Davidson Pfalzer, p.242.
  32. 32. Referências 15.5.1 The Agile Samurai: How masters deliver great softwares,Rasmusson Jonathan,Susannah Davidson Pfalzer, p.243. 15.6 The Agile Samurai: How masters deliver great softwares,Rasmusson Jonathan,Susannah Davidson Pfalzer, p.245. 15.8 The Agile Samurai: How masters deliver great softwares,Rasmusson Jonathan,Susannah Davidson Pfalzer, p.248.
  33. 33. Instituto Federal de Pernambuco. Aluno(a): Laura Regina Morais de Oliveira. Turma:2º período. Curso:Tecnologia em Análise e Desenvolvimento de Sistemas. Prof.:Marcos André. Disciplina: Engenharia de Software.

×