1
00:00:00,040 --> 00:00:04,800
Olá, seguimos nossa exploração 
sobre sinais de alerta no código

2
00:00:04,960 --> 00:00:07,600
os Coates mails. 
Com base no material de 

3
00:00:07,600 --> 00:00:11,680
engenharia de software Moderna, 
hoje vamos focar em como algumas

4
00:00:11,680 --> 00:00:15,080
práticas comuns podem, na 
verdade, esconder problemas de 

5
00:00:15,080 --> 00:00:17,400
design. 
A missão é identificar esses 

6
00:00:17,400 --> 00:00:19,480
pontos e entender o impacto 
deles. 

7
00:00:19,800 --> 00:00:22,720
Vamos lá. 
O primeiro da lista é a obsessão

8
00:00:22,720 --> 00:00:26,520
por tipos primitivos. 
Sabe aquela coisa de usar tipos 

9
00:00:26,520 --> 00:00:28,840
como o streaming ou wint pra 
tudo? 

10
00:00:29,120 --> 00:00:32,159
Até para representar conceitos 
que tem suas próprias regras, 

11
00:00:32,560 --> 00:00:36,920
tipo um CEP ou um e meio usando 
o som string simples. 

12
00:00:37,120 --> 00:00:39,640
Exato. 
E o interessante aqui não é só o

13
00:00:39,640 --> 00:00:42,520
que a gente faz, mas o que a 
gente deixa de fazer, né? 

14
00:00:42,880 --> 00:00:46,360
Quando você cria uma classe 
específica, tipo CEP, você ganha

15
00:00:46,360 --> 00:00:50,320
um lugar, um lugar natural para 
colocar validações formatações, 

16
00:00:50,320 --> 00:00:52,720
sabe? 
As regras de negócio daquele 

17
00:00:52,720 --> 00:00:56,160
conceito ficam ali usando só 
string, essa lógica acaba 

18
00:00:56,640 --> 00:00:58,560
espalhada. 
Repetida. 

19
00:00:58,560 --> 00:01:02,640
Repetida, inconsistente, às 
vezes pelo sistema, a gente 

20
00:01:02,640 --> 00:01:05,880
perde a chance de ter um 
guardião para aquele dado, para 

21
00:01:05,880 --> 00:01:09,400
aquele conceito específico. 
Faz todo o sentido. 

22
00:01:09,400 --> 00:01:11,200
Cria uma responsabilidade bem 
clara ali, né? 

23
00:01:12,040 --> 00:01:15,600
E essa ideia de objetos com 
responsabilidade me leva direto 

24
00:01:15,600 --> 00:01:19,480
para outro ponto, objetos 
mutáveis o material até cita o 

25
00:01:19,480 --> 00:01:23,040
Martin Fowler, que vê isso como 
um codes mel, mas. 

26
00:01:23,440 --> 00:01:26,840
Assim, qual é o problema de um 
objeto poder mudar de estado 

27
00:01:26,840 --> 00:01:29,960
depois de criado? 
Então, a questão central aqui é 

28
00:01:29,960 --> 00:01:36,440
a previsibilidade e a segurança.
O objeto imutável, depois que 

29
00:01:36,440 --> 00:01:39,800
você cria ele não muda mais o 
estado interno dele. 

30
00:01:40,040 --> 00:01:43,880
Pensa na string em Java, por 
exemplo, métodos como two 

31
00:01:43,880 --> 00:01:47,080
apurcase, eles não alteram a 
string original. 

32
00:01:47,320 --> 00:01:49,480
Ah, sim, eles criam uma nova. 
Né? 

33
00:01:49,480 --> 00:01:52,040
Exatamente. 
Criam e retornam uma nova 

34
00:01:52,040 --> 00:01:54,720
string. 
E isso traz vantagens assim, 

35
00:01:54,720 --> 00:01:59,480
enormes objetos imutáveis podem 
ser compartilhados sem medo 

36
00:01:59,600 --> 00:02:03,840
entre diferentes partes do 
código ou até entre treds, sem 

37
00:02:03,840 --> 00:02:07,680
aquele receio de que uma função 
modifique o estado que a outra 

38
00:02:07,680 --> 00:02:10,280
está usando, sabe? 
Isso simplifica muito o 

39
00:02:10,280 --> 00:02:13,080
raciocínio sobre o código, 
principalmente em sistemas 

40
00:02:13,080 --> 00:02:16,000
concorrentes. 
Entendi AA parte da segurança, 

41
00:02:16,080 --> 00:02:19,840
mas e a performance ficar 
criando objeto novo toda hora? 

42
00:02:20,080 --> 00:02:22,280
Isso não pode pesar. 
É uma troca, né? 

43
00:02:22,280 --> 00:02:26,440
Como quase tudo em engenharia de
software, em alguns cenários de 

44
00:02:26,440 --> 00:02:30,880
altíssima performance, sim, pode
ser um fator, mas olha para 

45
00:02:30,880 --> 00:02:33,960
maioria dos casos, especialmente
para objetos que representam 

46
00:02:33,960 --> 00:02:38,720
valores, tipo data, hora e-mail.
O próprio CEP que a gente falou.

47
00:02:39,160 --> 00:02:42,480
Os benefícios da clareza da 
segurança da manutenção 

48
00:02:42,760 --> 00:02:46,640
geralmente superam esse custo. 
E as linguagens os run times 

49
00:02:46,640 --> 00:02:49,360
modernos são bem otimizados para
isso hoje em dia. 

50
00:02:49,480 --> 00:02:52,320
Certo. 
A recomendação geral é preferir 

51
00:02:52,320 --> 00:02:55,800
a imutabilidade, usar recursos 
como o final em Java pra 

52
00:02:55,800 --> 00:02:58,600
atributos e classes sempre que 
fizer sentido, claro. 

53
00:02:58,680 --> 00:03:00,440
Interessante essa prespetiva da 
troca. 

54
00:03:00,440 --> 00:03:04,600
Bom, seguindo nessa linha de 
objetos e seus papéis classes de

55
00:03:04,600 --> 00:03:07,600
dados, aquelas classes que são 
basicamente um Monte de 

56
00:03:07,600 --> 00:03:11,040
atributos, talvez com gapters e 
setters, mas quase sem 

57
00:03:11,040 --> 00:03:15,680
comportamento próprio, parecem 
umas sacolas de dados. 

58
00:03:15,680 --> 00:03:19,600
Né, exato, tipo isso. 
E aqui o alerta não é que ela 

59
00:03:19,600 --> 00:03:23,600
seja um erro por si só, mas 
podem ser um sintoma, sabe? 

60
00:03:24,080 --> 00:03:27,400
O cheiro aqui levanta a 
pergunta, será que o 

61
00:03:27,400 --> 00:03:31,360
comportamento que opera nesses 
dados não deveria estar dentro 

62
00:03:31,360 --> 00:03:35,120
dessa classe? 
Hum, muitas vezes a lógica que 

63
00:03:35,120 --> 00:03:39,040
manipula os dados de uma classe 
de dados dessas está espalhada 

64
00:03:39,040 --> 00:03:42,680
em outras classes. 
Então a investigação é dá pra 

65
00:03:42,680 --> 00:03:45,400
gente mover essa lógica pra 
dentro da classe. 

66
00:03:45,880 --> 00:03:50,800
Para torná la mais coesa, mais 
responsável, transformar sacola 

67
00:03:50,800 --> 00:03:54,120
num objeto de verdade. 
É uma mudança de ponto de vista 

68
00:03:54,120 --> 00:03:56,640
sobre onde a lógica deveria 
morar, né? 

69
00:03:57,160 --> 00:04:00,280
E por falar em coisas que fazem 
a gente repensar práticas 

70
00:04:00,280 --> 00:04:05,120
comuns, o último ponto de hoje 
pode surpreender comentários 

71
00:04:05,120 --> 00:04:09,200
como colds, mel. 
Mas como assim comentar o código

72
00:04:09,200 --> 00:04:11,160
não é sempre bom, a gente 
aprende isso. 

73
00:04:11,240 --> 00:04:14,360
É surpreendente mesmo. 
A referência que o material traz

74
00:04:14,400 --> 00:04:18,040
é de corningham e plauger. 
Não comente código ruim 

75
00:04:18,160 --> 00:04:22,320
reescreva OA ideia não é acabar 
com todos os comentários, claro,

76
00:04:22,640 --> 00:04:25,520
mas é questionar aqueles que só 
existem pra explicar um código 

77
00:04:25,520 --> 00:04:27,480
confuso. 
Ah, entendi. 

78
00:04:27,480 --> 00:04:30,120
Se um pedaço de código é tão 
complicado que precisa de um 

79
00:04:30,120 --> 00:04:32,320
parágrafo de comentário pra 
alguém entender? 

80
00:04:32,680 --> 00:04:35,080
Talvez o problema seja o próprio
código, né? 

81
00:04:35,160 --> 00:04:38,160
Então, em. 
Vez de explicar o que o código 

82
00:04:38,160 --> 00:04:41,440
faz, o ideal é que o próprio 
código deixe isso claro. 

83
00:04:41,440 --> 00:04:46,800
Precisamente, a sugestão é 
refaturar extrair blocos lógicos

84
00:04:46,800 --> 00:04:50,840
para métodos com nomes claros. 
Descritivos o exemplo no 

85
00:04:50,840 --> 00:04:54,840
material é muito bom o método 
longo com comentários tipo passo

86
00:04:54,840 --> 00:04:58,240
um, passo 2. 
Uhum ao transformar cada passo 

87
00:04:58,240 --> 00:05:01,800
num método tipo executar, passo 
um, executar, passo 2. 

88
00:05:02,080 --> 00:05:05,160
O método original vira só uma 
sequência de chamadas que se 

89
00:05:05,160 --> 00:05:07,760
explicam sozinhas. 
Aí os comentários originais 

90
00:05:07,760 --> 00:05:10,960
ficam redundantes. 
Claro, comentários que explicam 

91
00:05:10,960 --> 00:05:13,880
o porquê de uma decisão de 
design que não é óbvia ou 

92
00:05:13,880 --> 00:05:16,960
documentação de API. 
Esses continuam super válidos, 

93
00:05:16,960 --> 00:05:19,280
certo? 
O cheiro é daquele comentário 

94
00:05:19,280 --> 00:05:22,360
que funciona como muleta para um
código que ninguém entende. 

95
00:05:22,640 --> 00:05:25,680
Entendido? 
Bom, recapitulando, então a 

96
00:05:25,680 --> 00:05:28,280
gente viu a obsessão por tipos 
primitivos. 

97
00:05:28,720 --> 00:05:33,680
A questão da mutabilidade versus
e mutabilidade as classes de 

98
00:05:33,680 --> 00:05:38,040
dados e até os comentários como 
sinais que merecem nossa atenção

99
00:05:38,040 --> 00:05:39,880
no código. 
São todos assim. 

100
00:05:39,960 --> 00:05:44,320
Lembretes importantes de que 
clareza e manutensabilidade não 

101
00:05:44,320 --> 00:05:48,400
acontece ainda Do Nada, né? 
São resultado de decisões 

102
00:05:48,400 --> 00:05:52,480
conscientes de design. 
Identificar esses cheiros é só o

103
00:05:52,480 --> 00:05:56,560
primeiro passo para a gente 
investigar, questionar essas 

104
00:05:56,560 --> 00:06:00,080
decisões. 
E quem sabe refaturar, buscando 

105
00:06:00,080 --> 00:06:03,040
um código mais robusto, mais 
compreensível? 

106
00:06:03,160 --> 00:06:07,080
Fica a reflexão, então, quanto 
desses cheiros a gente encontra 

107
00:06:07,080 --> 00:06:11,000
no nosso código do dia a dia? 
E o que eles realmente dizem 

108
00:06:11,000 --> 00:06:14,520
sobre nossos hábitos de design? 
Uma ótima questão pra gente 

109
00:06:14,520 --> 00:06:17,240
pensar. 
Agradecemos a atenção nesta 

110
00:06:17,240 --> 00:06:19,520
análise até o próximo episódio.