1. Quando fazer
2. O que não fazer
3. Um pouco do que fazer
Slide 8
Slide 8 text
@flafortes
Slide 9
Slide 9 text
Quais as motivações?
Slide 10
Slide 10 text
● Melhorar design do código
para facilitar adições e
extensões
Slide 11
Slide 11 text
● Satisfação em deletar
código
Slide 12
Slide 12 text
Vida real
● Cobrança por entrega
Slide 13
Slide 13 text
Vida real
● Cobrança por entrega
● Projeto com deadline
Slide 14
Slide 14 text
Vida real
● Cobrança por entrega
● Projeto com deadline
● Bugs em produção
Slide 15
Slide 15 text
Vida real
● Cobrança por entrega
● Projeto com deadline
● Bugs em produção
● Problemas de performance
Slide 16
Slide 16 text
Refatoração reativa
Slide 17
Slide 17 text
Impactos:
● Trabalhoso
Slide 18
Slide 18 text
Impactos:
● Trabalhoso
● Demorado
Slide 19
Slide 19 text
Impactos:
● Trabalhoso
● Demorado
● Difícil de testar
Slide 20
Slide 20 text
Impactos:
● Trabalhoso
● Demorado
● Difícil de testar
● Pode não entregar valor
para o usuário final
Slide 21
Slide 21 text
Então, como evitar
refatoração reativa?
Slide 22
Slide 22 text
Refatorando sempre, aos
poucos, ativamente.
Slide 23
Slide 23 text
Quais são os sinais do
dia-a-dia que me indicam
quando eu preciso refatorar
meu código?
Slide 24
Slide 24 text
Code smells
Slide 25
Slide 25 text
Métodos muito longos
Slide 26
Slide 26 text
Métodos com muitos
parâmetros
Slide 27
Slide 27 text
Métodos que usam mais dados
de outro objeto (Feature
envy)
Slide 28
Slide 28 text
O que costumamos fazer?
Slide 29
Slide 29 text
Extraímos lógica para outros
métodos menores
Slide 30
Slide 30 text
Models gigantescos
Slide 31
Slide 31 text
Muitos testes unitários, suite
de testes cada vez maior.
Slide 32
Slide 32 text
O que não costumamos fazer?
Slide 33
Slide 33 text
Pensar nas nossas classes com
poucos métodos públicos e
muitos métodos privados.
Slide 34
Slide 34 text
Pensar na nomenclatura da
API pública das nossas classes
com carinho.
Slide 35
Slide 35 text
Código mais legível é menos
complexo
Slide 36
Slide 36 text
Classes gigantes
Slide 37
Slide 37 text
Classes com muitas
propriedades
Slide 38
Slide 38 text
O que costumamos fazer?
Slide 39
Slide 39 text
Concerns
Slide 40
Slide 40 text
"Any application with an
app/concerns is concerning."
Slide 41
Slide 41 text
Composição > Herança
Slide 42
Slide 42 text
Service Objects
Slide 43
Slide 43 text
"The wrong object causes
more trouble than no object
at all." - Avdi Grimm
Slide 44
Slide 44 text
Enough with the service objects
already
https://avdi.codes/service-objects/
Slide 45
Slide 45 text
O que não costumamos fazer?
Slide 46
Slide 46 text
Extrair classes ruby puras
Slide 47
Slide 47 text
Classes de domínio
!=
Classes utilitárias
Slide 48
Slide 48 text
Single Responsibility Principle
Slide 49
Slide 49 text
"A class should do the
smallest possible thing." -
Sandi Metz
Slide 50
Slide 50 text
Código complexo nas views
Slide 51
Slide 51 text
O que costumamos fazer?
Slide 52
Slide 52 text
Presenters (Decorators)
Slide 53
Slide 53 text
"Cleaning up view code does
not mean hiding it in another
folder."
Slide 54
Slide 54 text
Thoughts about Rails
Presenters
https://gist.github.com/somebox/5
a7ebf56e3236372eec4
Slide 55
Slide 55 text
YAGNI (You ain't gonna need it)
● think of better abstractions?
● consider different naming?
● maybe you just need a new model?
Slide 56
Slide 56 text
Código duplicado
Slide 57
Slide 57 text
DRY
Don't Repeat Yourself
Slide 58
Slide 58 text
Vale lembrar: Em testes,
código duplicado não é
necessariamente algo ruim!
Slide 59
Slide 59 text
Alerta de polêmica:
Comentários no código
Slide 60
Slide 60 text
"Comments are always failures"
- Robert C. Martin
Slide 61
Slide 61 text
Comentários vs Documentação
Slide 62
Slide 62 text
Queime seus ídolos.
Slide 63
Slide 63 text
Código morto
Slide 64
Slide 64 text
O que não costumamos fazer?
Slide 65
Slide 65 text
Análise estática de código
Slide 66
Slide 66 text
Evitar metaprogramação
Slide 67
Slide 67 text
Teste complexo:
Slide 68
Slide 68 text
Teste complexo:
● Setup muito grande
Slide 69
Slide 69 text
Teste complexo:
● Setup muito grande
● Muitos stubs
Slide 70
Slide 70 text
Recapitulando...
Slide 71
Slide 71 text
Com refatorar melhor?
Slide 72
Slide 72 text
Estar atento aos sinais (code
smells).
Slide 73
Slide 73 text
Hábito continuo.
Slide 74
Slide 74 text
Exemplo: Tenho um projeto
com uma classe User muito
grande.
Slide 75
Slide 75 text
Meta: Na próxima feature que
envolver User, diminuir e não
aumentar a classe User.
Slide 76
Slide 76 text
Saber aplicação de design
patterns
!=
Saber refatorar
Slide 77
Slide 77 text
Pensamento crítico vale mais
que qualquer técnica de
refatoração ou Design Pattern
vendido como bala de prata.
Slide 78
Slide 78 text
"There is no refactoring that is always a
great idea. You always have to say: is
this worth it given the components of
my system as they are?" - Ben Orenstein