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