1 2 3 4 5 6 7 8 9 10 11 12 13 14 Apresentando ‘Marylly’ { < Desafios do código sustentável de alto valor > [Em busca do código Perfeito] } fordevelopers.html lecture.css 1

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Eu sou ‘Marylly’{ < Engenheira de Software, Tech Lead, Cultivadora da Cultura DevOps na ThoughtWorks. Menina e mulher de família de cor simples da periferia da capital de SP > fordevelopers.html lecture.css } 2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 01 < Como é nosso alecrim dourado > O que é código perfeito 02 < A realidade do código dos times > Realidade 03 < Práticas que ajudam a melhorar o cenário > O que podemos fazer Table Of ‘Agenda’ { } fordevelopers.html lecture.css 3

1 2 3 4 5 6 7 8 9 10 11 12 13 14 04 < Existe refatoração > Existe salvação? 05 < Práticas que contribuem > Não faço nada, dá para começar? 06 < Conclusões e aprendizados > E pra finalizar Table Of ‘Agenda’ { } fordevelopers.html lecture.css 4

1 2 3 4 5 6 7 8 9 10 11 12 13 14 01 { [O que é código perfeito] < Como é nosso alecrim dourado > } fordevelopers.html lecture.css 5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Features of ‘Código Perfeito’ { } 01 Organizado 02 Estruturado 03 Desacoplado 04 Modular fordevelopers.html lecture.css 6

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Features of ‘Código Perfeito’ { } 05 Simples 06 Fácil de ler 07 Fácil de entender 08 Testável fordevelopers.html lecture.css 7

1 2 3 4 5 6 7 8 9 10 11 12 13 14 02 { [Realidade] < A realidade do código dos times > } fordevelopers.html lecture.css 8

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Versão #0; {

O código no momento que está sendo construído, normalmente está no seu ideal de estrutura e entendimento. A partir do momento que o código está em ambiente produtivo, já podemos chamá-lo de legado. }

fordevelopers.html lecture.css ‘Primeiro Go Live’ 9

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Mudanças de regra de negócio Versão #n++ { < /1 > fordevelopers.html lecture.css } Novas funcionalidades < /2 > Manutenção < /3 > Bugs < /4 > Pessoas desenvolvedoras alterando o mesmo código < /5 > Pressão do mercado < /6 > Obrigações legais < /7 > Prazos apertados < /8 > 10

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Perda de velocidade de entrega Aumento progressivo de riscos Dificuldade de recuperação após falha Custo elevado de desenvolvimento Realidade sobre ‘Time’{ } fordevelopers.html lecture.css 11

1 2 3 4 5 6 7 8 9 10 11 12 13 14 — Andrew ‘Hunt’ e David ‘Thomas’ < “Codificar para o futuro é difícil.”> fordevelopers.html lecture.css 12

1 2 3 4 5 6 7 8 9 10 11 12 13 14 < Entropia ou deterioração do código é um processo lento de perda de valor tanto de negócio como capacidades funcionais e não-funcionais à medida que o tempo passa esse código sofre a falta de atualizações estruturais, arquiteturais e suas dependências, além de possuir um processo ineficaz de manutenção e evolução, podendo se tornar insustentável e inutilizável.> Entropia do Software { fordevelopers.html lecture.css } 13

1 2 3 4 5 6 7 8 9 10 11 12 13 14 03 { [O que podemos fazer] < Práticas que ajudam a melhorar o cenário > } fordevelopers.html lecture.css 14

1 2 3 4 5 6 7 8 9 10 11 12 13 14 fordevelopers.html ATENÇÃO { < NÃO EXISTE BALA DE PRATA > lecture.css } 15

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Práticas para ‘Times’ { Testes Automatizados Planejar o código Código Limpo (Clean Code) TDD BDD Sinergia com Negócio fordevelopers.html lecture.css } 16

1 2 3 4 5 6 7 8 9 10 11 12 13 14 04 { [Existe salvação?] < Existe refatoração > } fordevelopers.html lecture.css 17

1 2 3 4 5 6 7 8 9 10 11 12 13 14 < Processo de atualização do código do software de uma forma que não altere seu comportamento esperado, melhorando, simplificando e sanitizando o design do código.> Refatoração de código { fordevelopers.html lecture.css } 18

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Velocidade de entrega Mitigação riscos Software entregando maior valor Custo baixo de desenvolvimento Benefícios < /1 >{ } fordevelopers.html lecture.css 19

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Testes automatizados obrigatório Curva de aprendizagem Impacto na cultura do time Implantação Contrapontos < /2 >{ } fordevelopers.html lecture.css 20

1 2 3 4 5 6 7 8 9 10 11 12 13 14 05 { [Não faço nada, dá para começar?] < Práticas que contribuem > } fordevelopers.html lecture.css 21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Recomendações gerais; { < se for código legado, comece por uma funcionalidade nova, um bug fix simples ou pelo processo que mais necessita desta estrutura de apoio > < construa uma estrutura de testes de acordo com o que é possível executar com as pessoas e os recursos disponíveis > Apenas comece… < discuta e escute propostas que possam surgir para compor um plano de ação inicial > Construa com o time Priorize os fluxos de maior valor } fordevelopers.html lecture.css 22

1 2 3 4 5 6 7 8 9 10 11 12 13 14 06 { [E pra finalizar] < Conclusões e aprendizados > } fordevelopers.html lecture.css 23

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Conclusão { } fordevelopers.html lecture.css Não existe código perfeito; 24

O ‘Aprendizado’é { Código sustentável que entrega valor } 25

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Obrigada { Redes sociais: Marylly Silva @MaryllyOficial @MaryllyOficial fordevelopers.html lecture.css } ‘Perguntas?’ 26

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Contents Of ‘Referências’; ∗ Wikipedia: Deterioração do Software. Disponível em: https://pt.wikipedia.org/wiki/Deteriora%C3%A7%C3%A3o_de_software. Acesso em 22 de Maio de 2022 às 18:15. ∗ Hunt, Andrew; Thomas, David: O Programador Pragmático: de aprendiz ao mestre. Bookman, 2010. Página 69. ∗ Fowler, Martin: Refactoring: Improving the Design of Existing Code: Addison-Wesley, 2a edição. 2019. fordevelopers.html lecture.css