O documento discute como a entropia afeta a evolução de sistemas computacionais e como o refactoring pode ser usado para reduzir a entropia. Apresenta também os principais tipos de atrito ao refactoring, especialmente o atrito arquitetural relacionado a impactos desconhecidos e indesejáveis das mudanças. Defende três princípios do Design to Refactor: não se intrometer, não se comprometer e não se expor, para permitir refactors com menor impacto.

1. APLICAÇÕES QUE
EVOLUEM
D2R Principle: Refatoração como foco do design das
aplicações

2. ©ThoughtWorks 2018 Commercial in Confidence 2

3. ENTROPIA
3
Vamos falar de termodinâmica?

4. ©ThoughtWorks 2018 Commercial in Confidence
ENTROPIA: desordem interna de um sistema, ou ainda, tem a
ver com a irreversabilidade (espontânea) da ordem
4

5. ©ThoughtWorks 2018 Commercial in Confidence
Entropia em Sistemas Computacionais…
5
POR INTERVENÇÃO
A cada intervenção, a entropia do sistema
cresce de maneira exponencialmente
proporcional à atual entropia do sistema
POR POTENCIAL
A entropia do sistema cresce à medida em
que a diferença entre a ordem interna e a
ordem externa crescem

6. ©ThoughtWorks 2018 Commercial in Confidence
Como a entropia afeta a evolução de um sistema computacional?
6
ENTROPIA RESISTÊNCIA
À MUDANÇA

7. ©ThoughtWorks 2018 Commercial in Confidence
Software também morre!
7

8. ©ThoughtWorks 2018 Commercial in Confidence
Refactoring é a válvula de escape de
entropia do sistema...
8

9. Atrito ao Refactoring
A melhor forma de saber que um software morreu

10. ©ThoughtWorks 2018 Commercial in Confidence
"Tudo que, direta ou indiretamente,
impede, atrapalha ou desmotiva as pessoas
desenvolvedoras a refatorar um sistema."
10

11. ©ThoughtWorks 2018 Commercial in Confidence
Tipos de Atrito ao Refactoring
11
ATRITO CULTURAL
Muitas equipes trabalham
com mecanismos de
resistência a refactorings.
É muito comum equipes que
têm o mindset SCP
(smallest change possible,
ou "menor alteração
possível"). Mix up your images to match
your content.
ATRITO ARQUITETURAL
A equipe de desenvolvimento
tem receio de realizar
alterações devido ao impacto
que essas alterações podem
causar.
ATRITO SISTÊMICO
O negócio não muda mais, e o
sistema já atende ao negócio
de forma satisfatória.
ATRITO DE
CONHECIMENTO
A equipe não é fluente na
tecnologia em que está
trabalhando.

12. ©ThoughtWorks 2018 Commercial in Confidence
Quando percebo que não sei
qual o impacto que a
refatoração tem sobre o
funcionamento do sistema.
12
IMPACTO
DESCONHECIDO

13. ©ThoughtWorks 2018 Commercial in Confidence
Quando percebo que a
refatoração tem impacto em
algo que eu não quero ou
posso mudar.
13
IMPACTO
INDESEJÁVEL

14. ©ThoughtWorks 2018 Commercial in Confidence
Mas como fazer para diminuir o atrito ao
refactoring, permitindo que eu possa
controlar e entropia da minha aplicação?
14

15. 3 princípios do
Design to Refactor

16. ©ThoughtWorks 2017 Commercial in Confidence
FRONTEIRAS BEM DEFINIDAS
16
Unidades computacionais com
fronteiras bem definidas, em todas as
camadas, permitem reduzir o impacto
de alterações na aplicação
0

17. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE INTROMETA
17
Não se integre com outras unidades
computacionais de forma que você
tenha que conhecer o seu estado
interno para funcionar.
Exemplos: acessar uma base de dados
compartilhada; conhecer uma determinada
estrutura do sistema de arquivos compartilhada;
acessar atributos de um outro objeto via reflection;
1

18. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE INTROMETA
18
Exemplos:
● acessar uma base de dados compartilhada
● conhecer uma determinada estrutura do sistema de
arquivos compartilhada
● Acessar atributos de um outro objeto via reflection

19. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE COMPROMETA
19
Ao se integrar, não se comprometa a
fornecer ou conhecer mais informação
do que o mínimo necessário.
...protocolos de integração...
2

20. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA
20
3
Ao se integrar, não permita que
entidades externas conheçam a sua
estrutura interna.

21. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA
21
UNIDADE
COMPUTACIONAL
Outras unidades
computacionais
PersistênciaTestes

22. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA A OUTRAS UNIDADES COMPUTACIONAIS
"ENCAPSULAMENTO"
22

23. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA A OUTRAS UNIDADES COMPUTACIONAIS
"ENCAPSULAMENTO"
23

24. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA A OUTRAS UNIDADES COMPUTACIONAIS
"ENCAPSULAMENTO"
24

25. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA A OUTRAS UNIDADES COMPUTACIONAIS
"OBJECT MARSHALLING"
25
Aplicação 1 Aplicação 2
JSON
OBJ OBJ
marshalling unmarshalling

26. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA A OUTRAS UNIDADES COMPUTACIONAIS
"OBJECT MARSHALLING"
26
Aplicação 1 Aplicação 2
JSON
OBJ OBJ
marshalling unmarshalling
Schemas cheios de remendos
por que mudanças estruturais
têm impacto em múltiplas
camadas de múltiplas
aplicações
Eu não refatoro o código da
minha aplicação por que ele
depende de um schema que eu
não posso mudar sem impactar
outras aplicações

27. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA A OUTRAS UNIDADES COMPUTACIONAIS
"OBJECT MARSHALLING"
27
Aplicação 1 Aplicação 2
JSON
OBJ OBJ
"Tem certeza que vai usar marshalling? Então use com DTOs!"
SANTOS, FÁBIO
DTODTO

28. ©ThoughtWorks 2018 Commercial in Confidence
Pessoas Javistas…
Object Marshalling não é a única opção!!!
28

29. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA A OUTRAS UNIDADES COMPUTACIONAIS
"OBJECT MARSHALLING"
29

30. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA A OUTRAS UNIDADES COMPUTACIONAIS
"OBJECT MARSHALLING"
30

31. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA A OUTRAS UNIDADES COMPUTACIONAIS
"OBJECT MARSHALLING"
31

32. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA A OUTRAS UNIDADES COMPUTACIONAIS
"OBJECT MARSHALLING"
32

33. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA À BASE DE DADOS
"OBJECT-RELATIONAL MAPPING"
33
OBJ DB
ORM-Hibernate
Como entidades independentes (tanto em
termos de estrutura quanto de
infraestrutura) código e base de dados têm
ciclos evolutivos diferentes.
Acredite, você não vai evoluir o seu código
porque isso impacta a estrutura de
persistência dos teus dados.
Isso vale tanto para persistência SQL e
noSQL.

34. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA À BASE DE DADOS
"OBJECT-RELATIONAL MAPPING"
34
DTO DB
ORM-Hibernate
OBJ

35. ©ThoughtWorks 2018 Commercial in Confidence
EFEITO COLATERAL: O Inferno dos DTOs
35

36. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA AOS TESTES
"TESTES CAIXA BRANCA E MOCKS"
36
"Se toda vez que você refatora o seu código
você tem que alterar os seus testes, então
você não refatora o seu código"
SANTOS, FÁBIO

37. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA AOS TESTES
"TESTES CAIXA BRANCA E MOCKS"
37
"Não é por que são unitários que os testes
devem deixar de testar comportamentos
para testar interações. Testes unitários
assim são chamados por que testam
comportamentos unitários, e não unidades
de código."
SANTOS, FÁBIO

38. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA À BASE DE DADOS
"TESTES CAIXA BRANCA E MOCKS"
38
O grande desafio é como testar orquestração...

39. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA À BASE DE DADOS
"TESTES CAIXA BRANCA E MOCKS"
39

40. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA À BASE DE DADOS
"TESTES CAIXA BRANCA E MOCKS"
40
ISOLATE FEATURE FROM INTEGRATION

41. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA À BASE DE DADOS
"TESTES CAIXA BRANCA E MOCKS"
41
ISOLATE FEATURE FROM INTEGRATION

42. ©ThoughtWorks 2017 Commercial in Confidence
NÃO SE EXPONHA À BASE DE DADOS
"TESTES CAIXA BRANCA E MOCKS"
42
ISOLATE FEATURE FROM INTEGRATION

43. ©ThoughtWorks 2018 Commercial in Confidence
Resumindo... ENTROPIA
A desordem interna de um sistema evolui à medida em que se fazem novas intervenções
e/ou à medida em que o mundo à sua volta muda.
Entropia gera resistência à mudança, potencialmente levando software à morte.
REFACTORING COMO VÁLVULA DE ESCAPE
Refactoring permite diminuir a entropia do sistema e deve ser feito continuamente para
amenizar e/ou reverter a desordem gerada por intervenções diretas ou mesmo por
mudanças externas ao sistema.
ATRITO AO REFACTORING
Além do Atrito Cultural e Sistêmico, o Atrito Arquitetural, resumido como Impacto
Desconhecido e Impacto Indesejável, foi o ponto de atenção principal da nossa conversa
hoje.
NÃO SE INTROMETA
NÃO SE COMPROMETA
NÃO SE EXPONHA
43

44. MUITO OBRIGADO
Perguntas e sugestões:
Fábio Santos
fsantos@ThoughtWorks.com
44