O documento discute a importância da reconstrução contínua e integração do código para manter a qualidade e prontidão do software. Ele explica que pequenas modificações frequentes no código permitem mudanças futuras menos trabalhosas. Também descreve os benefícios da integração contínua como a capacidade de demonstrar o produto a qualquer momento.

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. 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. Reconstrução de código
Imagem 13.2

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. 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. 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. 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. Reconstrução consistente e contínua
Imagem 13.3.1

9. Reconstrução consistente e contínua
Imagem 13.3.2

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. 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. 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. 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. 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. 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. Repositório de código
❖ Possuir um único local para todos da equipe alocarem o código e
editarem
Imagem 15.3

17. Processo automatizado de check-in do
código
Imagem 15.5

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. 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. Boas e más práticas no processo de check-
in do código
Imagem 15.5.1

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. 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. 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. Criação de um teste automatizado
Imagem 15.6

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. 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. E se o programador não tiver permissão para
aplicar métodos ágeis ?
Imagem 15.8

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. 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. 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. 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. 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. 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.