Upgrade to Pro — share decks privately, control downloads, hide ads and more …

O que fazer quando o sistema se torna um monstr...

O que fazer quando o sistema se torna um monstrinho?, PythonBrasil 2021

Todo developer na indústria já teve que enfrentar diversos monstrinhos de código e fluxos legados nos sistemas das empresas. Essa palestra compartilha conhecimentos e experiências sobre como lidar e resolver esses problemas, com exemplos tanto para monolitos como para microserviços. Venha aprender a refatorar código e fluxos legados de forma segura e eficiente, e como avaliar a prioridade e impactos da refatoração.
----------------------
Jéssica Bonson é Principal Engineer no iFood, com cerca de 8 anos de experiência de desenvolvimento. Já melhorou partes legadas de diversos sistemas. Isso inclui ETLs, sistemas de autenticação, logística, e fluxos em microserviços de catalogação, moderação e inteligência de estoque e preço. Além, é claro, de refatoração de classes e métodos dentro de um único projeto.
----------------------
Tópicos: Refatoração, testes, arquitetura, código e fluxos legados

Jessica Pauli de C Bonson

October 12, 2021
Tweet

More Decks by Jessica Pauli de C Bonson

Other Decks in Technology

Transcript

  1. O que fazer quando o sistema se torna um monstrinho?

    Jéssica Bonson Principal Engineer no iFood Python Brasil, 2021
  2. OLÁ! Eu sou Jéssica Bonson (@jpbonson) Principal Engineer @ iFood

    2 ⬢ Graduação/Mestrado em Ciências da Computação ⬢ 9+ anos de experiência em techstacks e projetos diversos
  3. “ O principal propósito da refatoração é fazer com que

    programemos mais rápido, agregando mais valor com menos esforço. Martin Fowler 4
  4. O QUE É REFATORAÇÃO? ⬢ Melhorar a estrutura interna, mas

    mantendo a funcionalidade ⬡ Diminui bugs ⬡ Aumenta produtividade ⬡ Mais fácil de entender 5
  5. QUANDO REFATORAR? ⬢ Mudança de foco contínua ⬡ Refactor ⬡

    Feature Atenção em manter o mesmo foco em Pull Requests!
  6. MAUS CHEIROS ⬢ Nome misterioso ⬢ Código duplicado ⬢ Função

    longa ⬢ Classe grande ⬢ Dados globais ⬢ Inveja de recursos ⬢ Comentários ⬢ Muitos parâmetros Mais exemplos em “Refatoração”, Martin Fowler, 2020
  7. “ Se eu deparar com um código confuso, mas que

    não precisa ser modificado, não terei de refatorá-lo. Martin Fowler 9
  8. BOAS PRÁTICAS ⬢ Versionamento ⬢ Integração Contínua / Entrega Contínua

    (CI/CD) ⬢ Testes automatizados ⬢ Code Reviews ⬢ Evitar otimização prematura ⬢ Usar Padrões e Frameworks ⬢ Conhecer Princípios do Design de Software ⬡ SOLID, KISS, Composition over inheritance...
  9. BOAS PRÁTICAS EM TESTES ⬢ Para códigos novos e debugs:

    ⬡ TDD (Test-Driven Development) ⬢ Para códigos legados sem testes: ⬡ Escrever teste com um valor qualquer ⬡ Testar e substituir pelo valor real ⬡ Injetar uma falha ⬡ Remover a falha
  10. QUANDO NÃO PRIORIZAR? ⬢ Não por motivos como “feio” ou

    “diferente” ⬢ É automatizável (use ferramentas, como linters) ⬢ Complexidade != Qualidade
  11. QUANDO NÃO PRIORIZAR? ⬢ Preocupação com performance ⬡ É mais

    fácil melhorar a performance de um código bem organizado ⬡ O impacto na performance costuma ser superestimado ⬡ Faça medições de desempenho, não especule
  12. COMO PRIORIZAR? ⬢ Foco em produtividade, não em “beleza” ⬡

    Tempo, bugs, custo… ⬢ Alinhe com o time, não faça sozinho ⬢ Tasks de refatoração devem ter a mesma atenção e debate que tasks de features 18
  13. 20 Teoria da Restrição Tripla (na prática para devs) Não

    é debatível Foco dos gestores Foco dos devs
  14. 21 Teoria da Restrição Tripla (na prática para devs) Não

    é debatível Foco dos gestores Foco dos devs Foco do debate
  15. APRENDIZADOS COM MONOLÍTOS ⬢ Antes de grandes refatorações ⬡ Garantir

    que haja um conjunto de testes automáticos robustos para a seção de código ⬡ Definição e testes dos contratos ⬡ Documentar 23
  16. APRENDIZADOS COM MONOLÍTOS ⬢ Composição > Herança ⬡ Reuso de

    código, sem perder flexibilidade ⬡ Cuidado com excesso de heranças 24
  17. “ Uma arquitetura boa vêem de compreendê-la mais como uma

    jornada do que como um destino. Robert C. Martin (Uncle Bob) 26
  18. APRENDIZADOS COM MICROSERVIÇOS ⬢ Trade-off Monolíticos vs Microserviços ⬡ Menos

    acoplamento, mas mais complexidade ⬢ Não são acoplados por código, mas são acoplados por dados ⬡ Contratos devem ser bem definidos e flexíveis ⬢ Devem seguir os Princípios de Design de Código ⬢ Evitar comunicação síncrona ⬢ Evitar precisar de deploys sincronizados 27
  19. APRENDIZADOS COM MICROSERVIÇOS ⬢ E se preciso alterar um campo

    em vários serviços? ⬡ Abordagem expansão-contração ⬡ Exemplo: Renomear um campo A para B i. Adiciona o campo B, sem usar ii. Escrita tanto em A como em B • Possível alteração no histórico iii. Leitura apenas em B iv. Aguardar/Corrigir bugs v. Remover campo A 28
  20. APRENDIZADOS COM MICROSERVIÇOS ⬢ Bibliotecas compartilhadas ⬡ Construir mais rápido

    usando o que já existe ⬡ Cuidado para não ficar muito grande ⬡ Cuidado com excesso de dependências ⬢ Definir padrões internos de arquitetura 29
  21. APRENDIZADOS COM MICROSERVIÇOS ⬢ Estratégias para refatorar um monolito em

    microserviços ⬡ Implementar novas funcionalidades como serviços ⬡ Extrair serviços do monolíto (strangling pattern) Também são úteis na refatoração de microserviços, evitando viradas-de-chave 30
  22. “ Em vez de uma construção, um software é mais

    como jardinagem - é mais orgânico do que concreto. “O Programador Pragmático” 31
  23. REFERÊNCIAS 33 Presentation template by SlidesCarnival Semantic Versioning 2.0.0 |

    Semantic Versioning 12 Software Design Key Principles Microservices (Martin Fowler) Refactoring a Monolith to microservices
  24. MAIS BOAS PRÁTICAS EM TESTES ⬢ Usar fixtures ⬢ Testes

    sem interdependências ⬢ Mais testes no caminho crítico ⬢ Testar os edge cases ⬢ Ferramentas para cobertura de testes ⬢ Organização arrange-act-assert ⬢ Foco em legibilidade ⬢ Prioridade: Baixo nível -> Alto nível
  25. “ Qualquer tolo escreve um código que um computador possa

    entender. Bons programadores escrevem códigos que os seres humanos podem entender. Martin Fowler 36
  26. “ Um sistema com um design ruim é difícil de

    ser alterado - porque é difícil identificar o que deve ser modificado, (...) [então] há uma boa chance de que vou cometer erros e introduzir bugs. Martin Fowler 37
  27. “ Se o código estiver funcionando e não tiver de

    ser alterado, deixá-lo como está não é um problema. (...) Contudo, assim que alguém precisar entender como esse código funciona e tiver dificuldade para saber o que ele faz, será necessário tomar alguma atitude a respeito. Martin Fowler 38
  28. “ O verdadeiro teste para um bom código é a

    facilidade com que ele pode ser alterado. Martin Fowler 39
  29. “ O segredo para uma refatoração eficaz é reconhecer que

    você será mais rápido se der passos minúsculos. Martin Fowler 40
  30. “ Build your system so that you can deploy it

    into jars, or into microservices, or anywhere in between. Robert C. Martin (Uncle Bob) 41