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

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. 1 PRINCÍPIOS DA REFATORAÇÃO
4. “ O principal propósito da refatoração é fazer com que programemos mais rápido, agregando mais valor com menos esforço. Martin Fowler 4
5. O QUE É REFATORAÇÃO? ⬢ Melhorar a estrutura interna, mas mantendo a funcionalidade ⬡ Diminui bugs ⬡ Aumenta produtividade ⬡ Mais fácil de entender 5
6. COMO REFATORAR? Processo cíclico com passos curtos, mantendo a funcionalidade. 6 Ler Entender Refatorar Testar Commit
7. QUANDO REFATORAR? ⬢ Mudança de foco contínua ⬡ Refactor ⬡ Feature Atenção em manter o mesmo foco em Pull Requests!
8. 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
9. “ Se eu deparar com um código confuso, mas que não precisa ser modificado, não terei de refatorá-lo. Martin Fowler 9
10. 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...
11. 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
12. 2 EXPERIÊNCIAS E APRENDIZADOS
13. QUANDO PRIORIZAR? ⬢ Intuição e experiência, não há métricas certeiras Feature Refatoração
14. QUANDO PRIORIZAR? Feature Refatoração Projetos falham Debug eterno Entregas lentas
15. QUANDO PRIORIZAR? Refatoração Feature “Enxugar gelo” Perda de apoio de negócios / produto
16. QUANDO NÃO PRIORIZAR? ⬢ Não por motivos como “feio” ou “diferente” ⬢ É automatizável (use ferramentas, como linters) ⬢ Complexidade != Qualidade
17. 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
18. 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
19. 19 Teoria da Restrição Tripla
20. 20 Teoria da Restrição Tripla (na prática para devs) Não é debatível Foco dos gestores Foco dos devs
21. 21 Teoria da Restrição Tripla (na prática para devs) Não é debatível Foco dos gestores Foco dos devs Foco do debate
22. 3 LIÇÕES APRENDIDAS Monolitos
23. 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
24. APRENDIZADOS COM MONOLÍTOS ⬢ Composição > Herança ⬡ Reuso de código, sem perder flexibilidade ⬡ Cuidado com excesso de heranças 24
25. 3 LIÇÕES APRENDIDAS Microserviços
26. “ Uma arquitetura boa vêem de compreendê-la mais como uma jornada do que como um destino. Robert C. Martin (Uncle Bob) 26
27. 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
28. 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
29. 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
30. 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
31. “ Em vez de uma construção, um software é mais como jardinagem - é mais orgânico do que concreto. “O Programador Pragmático” 31
32. REFERÊNCIAS 32 Presentation template by SlidesCarnival
33. 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
34. VALEU! @jpbonson 34
35. 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
36. “ 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
37. “ 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
38. “ 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
39. “ O verdadeiro teste para um bom código é a facilidade com que ele pode ser alterado. Martin Fowler 39
40. “ O segredo para uma refatoração eficaz é reconhecer que você será mais rápido se der passos minúsculos. Martin Fowler 40
41. “ Build your system so that you can deploy it into jars, or into microservices, or anywhere in between. Robert C. Martin (Uncle Bob) 41