O documento discute como melhorar códigos ruins através de boas práticas de programação como Test Driven Development (TDD), princípios SOLID e uso de comentários. Ele também explica porque códigos tendem a piorar com o tempo devido à saída de desenvolvedores experientes e medo de novos desenvolvedores modificarem o código.

1. Hora da aventura!
Vamos melhorar seu código?!?
@yuizinha

2. Anna "Yui" Cruz

6. O que contribui para um código feio?

7. O que contribui para um código feio?

8. O que contribui para um código feio?

9. O que contribui para um código feio?

10. O que contribui para um código feio?

11. Tá tudo pronto, só falta testar!
O que contribui para um código feio?

12. Porque o código continua feio?

13. Porque o código continua feio?
● Desenvolvedores experientes saem do projeto

14. Porque o código continua feio?
● Desenvolvedores experientes saem do projeto
● Novos desenvolvedores entram no projeto e
tem medo de modificar algo

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

16. Oh não!?!?!
O que podemos
fazer então?

18. Comentários!

21. Código auto-explicativo
Use comentários com calma, pense se são realmente
necessários

22. Use Test Driven
Development

23. TDD
Pequenas porções de código

24. TDD
Desenvolva apenas o necessário

25. TDD
Refatoração sem medo

26. TDD
RED
GREENREFACTOR

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

32. Single Responsibility
Uma classe/método, uma responsabilidade

33. Single Responsibility
Classes e métodos pequenos e coesos

34. Single Responsibility
Mais fácil de manter

36. Open-closed
Classes abertas para extender

37. Open-closed
Classes fechadas para modificação

38. Open-closed
Diminui o acoplamento entre as classes

40. Barbara Liskov
Cientóloga da computação
Professora do MIT
Criadora da linguagem CLU
Vencedora do Prêmio Turing
Diversos artigos acadêmicos

41. Liskov substituition
Uma classe pode ser substituida por uma subclasse

42. Liskov substituition
Manutenção de contrato entre classes

43. Liskov substituition
Diminui o acoplamento, melhora o reaproveitamento

45. Interface segregation
Interfaces especializadas

46. Interface segregation
Interfaces sem conter métodos desnecessários

47. Interface segregation
Gerar interfaces pequenas e coesas

49. Dependency inversion
Abstrações não devem depender de detalhes

50. Dependency inversion
Classes de alto nível não devem depender de classes de
baixo nível

51. Dependency inversion
Um problema, uma classe

52. Dependency inversion
Mais flexibilidade para "troca" de dependências

55. Links
http://amzn.to/2dRdlaf
http://bit.ly/2dYKQb7
http://amzn.to/2dTFthn

56. acruz@thoughtworks.com
anna.cruz@gmail.com
@yuizinha
annacruz.github.io