O documento discute como melhorar a qualidade do código através de boas práticas como SOLID e código limpo. Isso melhora a manutenibilidade ao tornar o código mais fácil de compreender e corrigir bugs. Comentários devem ser usados com moderação para explicar partes complexas em vez de repetir o código.

1. De Freddy Krueger à Brad Pitt.
Como melhorar o seu código e fazê-lo ficar lindo

2. Analista de Desenvolvimento no SERPRO &
ex-Analista de Infra & @rubyonrio &
@hackinrio & WTM & curiosa & hiperativa &
tentando dominar o mundo
Quem sou eu?

3. O que vamos ver?
• SOLID (Boas práticas)
• Código Limpo

4. O que vamos ver?
• SOLID (Boas práticas)
• Código Limpo

5. Tá mas porque isso é
importante?
● Mais fácil para compreender
● Mais fácil de encontrar e resolver bugs
Ou seja, melhora (e muito) a MANTENABILIDADE
do código

7. O que contribui para um código
feio?
Eu quero é terminar rápido!!!
Pra que fazer direito? Tô de saco cheio desse
projeto já!
Tenho que começar a fazer agora!!!
Depois refatoro!
Todo mundo faz assim!!!

8. O que contribui para um código
feio?
Eu quero é terminar rápido!!!
Pra que fazer direito? Tô de saco cheio desse
projeto já!
Tenho que começar a fazer agora!!!
Depois refatoro!
Todo mundo faz assim!!!

9. Porque o código continua feio?
● Desenvolvedores saem do projeto
● Novos desenvolvedores entram no projeto e
tem medo de modificar algo
● Mito de que demora muito mais tempo

10. O poder de mudar isso é nosso!

11. Respire fundo e....

12. E os comentários????
Não use!

13. Palma palma palma! Não
priemos cânico!!!

14. O código deve ser o máximo possível
auto-explicativo
Comentários podem e devem ser
usados, mas principalmente nas
seguintes condições:
● Se não dá pra fazer nada melhor.
● Para alertar sobre algo importante sobre
aquele trecho de código.
● TODO / FIXME

15. Ou seja...

16. Ou seja...

17. S
O
L
I
D
ingle Responsibility
pen-Closed
iskov Substitution
nterface Segregation
ependency Inversion

19. Single Responsibility
Cada classe ou método deve ter apenas uma
responsabilidade, ou seja, mudar por apenas
um motivo

20. Single Responsibility
Cada classe ou método deve ter apenas uma
responsabilidade, ou seja, mudar por apenas
um motivo
Objetivo:
● Classes ou métodos pequenas e coesas e
fracamente acopladas

22. Open-Closed
As classes devem ser abertas para extensão,
mas fechadas para modificação.

23. Open-Closed
As classes devem ser abertas para extensão,
mas fechadas para modificação.
Objetivos:
● Evolução do código mais fácil e rápida
● Melhorar a testabilidade

24. Open-Closed

25. Liskov Substitution
Uma classe pode ser substituída por uma
classe derivada dela sem a alteração de
funcionamento de um método.

26. Liskov Substitution
Uma classe pode ser substituída por uma
classe derivada dela sem a alteração de
funcionamento de um método.
Objetivos:
● Reaproveitamento de código mais eficiente
● Melhorar a testabilidade

27. Liskov Substitution

29. Interface Segregation
O cliente de uma classe não deve ser
obrigado a herdar métodos que ele não
utiliza.

30. Interface Segregation
O cliente de uma classe não deve ser
obrigado a herdar métodos que ele não
utiliza.
Objetivo:
● Interfaces menores, mais coesas e mais
estáveis

31. Interface Segregation

32. Dependency Inversion
Módulos de alto nível não devem depender de
módulos de baixo nível e sim de abstrações e
estas não devem depender de detalhes e sim
os detalhes dependerem delas.

33. Dependency Inversion
Módulos de alto nível não devem depender de
módulos de baixo nível e sim de abstrações e
estas não devem depender de detalhes e sim
os detalhes dependerem delas.
Objetivos:
● Diminuir o acoplamento entre os diferentes
módulos
● Aumentar o reuso de classes

34. Dependency Inversion

35. Vamos lembrar sempre
Isso são apenas boas práticas, não resolvem
todos os problemas...

37. anna.cruz@gmail.com
@yuizinha