1
00:00:00,040 --> 00:00:02,960
Olá, bem vindos. 
A mais uma análise detalhada 

2
00:00:02,960 --> 00:00:07,360
aqui no the deb Dive. 
Hoje vamos mergulhar num tema 

3
00:00:07,360 --> 00:00:12,080
bem central pra quem desenvolve 
software, a revisão de código é 

4
00:00:12,080 --> 00:00:14,720
uma prática. 
Que bom, muita gente já ouviu 

5
00:00:14,720 --> 00:00:17,440
falar, né? 
Mas a gente vai tentar entender 

6
00:00:17,440 --> 00:00:20,680
melhor. 
E pra nos guiar nessa conversa, 

7
00:00:20,880 --> 00:00:25,440
a gente tá usando como base o 
capítulo 22 do livro, coletânea 

8
00:00:25,440 --> 00:00:29,240
de artigos didáticos engenharia 
de software Moderna. 

9
00:00:29,480 --> 00:00:33,400
Os autores são a Aline Torres e 
o Marco Túlio Valente. 

10
00:00:33,880 --> 00:00:37,720
Então, a nossa missão aqui hoje 
é desvendar o que é exatamente 

11
00:00:37,720 --> 00:00:41,080
essa revisão de código. 
Porque era tão falada, tão 

12
00:00:41,080 --> 00:00:44,840
importante e, claro, como fazer 
isso de um jeito que realmente 

13
00:00:44,840 --> 00:00:48,120
traga resultados? 
Tudo baseado nesse material e 

14
00:00:48,120 --> 00:00:50,680
olha que interessante. 
Só para dar um gostinho, uma 

15
00:00:50,680 --> 00:00:56,520
pesquisa lá do stackverflow de 
2019 já mostrava que mais de 75%

16
00:00:56,520 --> 00:00:58,640
dos desenvolvedores que 
responderam. 

17
00:00:58,880 --> 00:01:01,520
Já usavam revisão de código no 
trabalho. 

18
00:01:01,520 --> 00:01:04,200
Pois é, não é algo exatamente 
novo, né? 

19
00:01:04,519 --> 00:01:08,280
Mas ainda assim tem muitos 
detalhes, muitas formas de 

20
00:01:08,280 --> 00:01:09,680
fazer. 
Exato. 

21
00:01:10,160 --> 00:01:14,160
Então vamos lá. 
Começando pelo básico mesmo, o 

22
00:01:14,160 --> 00:01:17,240
que é, afinal, essa tal de 
revisão de código? 

23
00:01:17,680 --> 00:01:21,200
A ideia central assim me parece 
simples, um desenvolvedor 

24
00:01:21,200 --> 00:01:23,960
escreve um código ou mexe em um 
existente? 

25
00:01:24,120 --> 00:01:26,480
Isso. 
E antes desse código ir para o 

26
00:01:26,480 --> 00:01:30,280
lugar oficial do projeto, para a
base principal, pelo menos um 

27
00:01:30,280 --> 00:01:34,040
outro colega, o revisor, dá uma 
olhada nele, é isso? 

28
00:01:34,360 --> 00:01:37,280
É isso. 
Mas essa olhada é mais do que 

29
00:01:37,280 --> 00:01:40,680
uma simples leitura, sabe? 
Na prática, vira quase um 

30
00:01:40,680 --> 00:01:43,960
diálogo técnico. 
Geralmente, isso acontece dentro

31
00:01:43,960 --> 00:01:46,600
de ferramentas específicas que 
ajudam muito. 

32
00:01:46,880 --> 00:01:50,280
O revisor analisa e pode deixar 
comentários. 

33
00:01:50,440 --> 00:01:54,560
Comentários tipo. 
É a mesma coisa, pode pedir para

34
00:01:54,560 --> 00:01:58,920
esclarecer uma parte do código 
que não ficou tão clara ou até 

35
00:01:58,920 --> 00:02:01,760
propor uma solução completamente
diferente? 

36
00:02:02,080 --> 00:02:04,760
Entendi e o autor do código faz 
o quê? 

37
00:02:05,320 --> 00:02:08,479
O autor, então, vê esses 
comentários e responde. 

38
00:02:08,880 --> 00:02:13,680
Ele pode concordar e ajustar o 
código, ou então explicar porque

39
00:02:13,680 --> 00:02:17,200
que a solução original que ele 
fez é melhor naquele contexto 

40
00:02:17,200 --> 00:02:20,640
específico. 
O objetivo final é chegar num 

41
00:02:20,640 --> 00:02:23,720
consenso, né? 
Para que o código seja aprovado 

42
00:02:23,720 --> 00:02:25,840
e possa ser integrado ao projeto
principal. 

43
00:02:25,920 --> 00:02:28,880
Faz sentido? 
E como isso funciona? 

44
00:02:29,160 --> 00:02:32,760
Assim, no dia a dia, o material 
fala muito de purequests ou 

45
00:02:32,760 --> 00:02:35,200
pias, especialmente no GitHub, 
né? 

46
00:02:35,680 --> 00:02:38,160
Acho que vale a pena explicar 
rapidinho o que é um pior pra 

47
00:02:38,160 --> 00:02:43,000
quem talvez não use tanto. 
Boa ideia um pover Quest ou PR é

48
00:02:43,000 --> 00:02:45,200
basicamente uma solicitação 
formal. 

49
00:02:45,520 --> 00:02:49,400
O desenvolvedor que mexeu no 
código pede, olha, eu fiz essas 

50
00:02:49,400 --> 00:02:52,680
alterações aqui, vocês podem 
revisar pra gente poder juntar 

51
00:02:52,680 --> 00:02:56,520
isso ao código principal. 
É esse pedido que dispara todo o

52
00:02:56,520 --> 00:02:59,040
processo de revisão e a 
discussão que a gente tá 

53
00:02:59,040 --> 00:03:02,000
falando. 
A ferramenta organiza isso. 

54
00:03:02,000 --> 00:03:04,440
Perfeito. 
E o capítulo dá até um exemplo 

55
00:03:04,440 --> 00:03:06,200
prático disso, né? 
Como a classe chamada 

56
00:03:06,200 --> 00:03:08,920
estacionamento. 
Sem entrar nos detalhes do 

57
00:03:08,920 --> 00:03:12,160
código em si, que não é o foco 
aqui, mas a dinâmica foi mais ou

58
00:03:12,160 --> 00:03:14,400
menos assim. 
Uma desenvolvedora criou essa 

59
00:03:14,400 --> 00:03:17,320
classe, submeteu o PR, aí veio o
revisor. 

60
00:03:17,320 --> 00:03:20,200
Isso, ele olhou o código e fez 
alguns comentários. 

61
00:03:20,440 --> 00:03:23,320
Sugeriu, por exemplo, deixar 
alguns atributos privados, 

62
00:03:23,480 --> 00:03:26,440
implementar um método específico
lá ou estaciona. 

63
00:03:26,800 --> 00:03:29,840
A autora concordou com as 
sugestões, fez os ajustes no 

64
00:03:29,840 --> 00:03:33,880
código e atualizou OPRE. 
Aí aí o revisor olhou de novo e 

65
00:03:33,880 --> 00:03:37,640
deu OOK dele. 
Usou até a sigla LGTM, né? 

66
00:03:37,840 --> 00:03:44,000
Que é luks good To Me. 
Ah sim, o famoso LGTM pra mim, 

67
00:03:44,000 --> 00:03:46,440
tá bom? 
Exato, e só depois dessa 

68
00:03:46,440 --> 00:03:49,760
aprovação é que o código foi 
finalmente integrado ao projeto.

69
00:03:49,800 --> 00:03:52,760
E o bacana de notar aí é 
justamente o papel dessas 

70
00:03:52,760 --> 00:03:56,560
ferramentas, como o GitHub. 
Elas não só permitem que isso 

71
00:03:56,560 --> 00:03:58,920
aconteça, mas organizam a coisa 
toda. 

72
00:03:59,240 --> 00:04:02,920
Imagina tentar fazer isso por 
e-mail ou numa conversa rápida 

73
00:04:02,920 --> 00:04:05,360
no corredor? 
Ficaria uma bagunça, né? 

74
00:04:05,400 --> 00:04:07,880
Nossa, nem me fale. 
Com a ferramenta, cada 

75
00:04:07,880 --> 00:04:11,080
comentário, cada resposta, cada 
versão do código fica 

76
00:04:11,080 --> 00:04:14,040
registrada. 
Isso tem um histórico super 

77
00:04:14,040 --> 00:04:16,600
útil. 
Dá para voltar depois e entender

78
00:04:16,600 --> 00:04:19,040
por que certas decisões foram 
tomadas lá atrás? 

79
00:04:19,040 --> 00:04:22,720
É verdade, essa rastreabilidade 
é um ponto forte mesmo. 

80
00:04:22,840 --> 00:04:26,880
Mas, pensando bem, dedicar esse 
tempo todo para revisar o código

81
00:04:26,880 --> 00:04:28,520
dos outros. 
Por que? 

82
00:04:28,840 --> 00:04:31,400
Quais são as motivações reais 
por trás disso? 

83
00:04:31,960 --> 00:04:34,280
O artigo cita um estudo bem 
legal sobre isso. 

84
00:04:34,400 --> 00:04:40,920
SIM, 1 estudo da Microsoft de 
2013 feito por bakhele e birt. 

85
00:04:41,440 --> 00:04:46,760
Eles conversaram com quase 900 
pessoas, entre desenvolvedores e

86
00:04:46,760 --> 00:04:49,360
testadores. 
E o que eles descobriram? 

87
00:04:49,560 --> 00:04:51,640
Qual a razão número 1 para 
revisar código? 

88
00:04:52,120 --> 00:04:55,680
A principal, talvez a mais 
óbvia, é realmente encontrar 

89
00:04:55,680 --> 00:05:00,960
bugs, achar falhas, erros de 
lógica, antes que isso vá para a

90
00:05:00,960 --> 00:05:03,280
produção e cause problemas 
maiores. 

91
00:05:03,400 --> 00:05:07,000
Claro, essa é fundamental. 
Mas o estudo mostrou que vai 

92
00:05:07,000 --> 00:05:09,800
além disso, né? 
Outros motivos importantes que 

93
00:05:09,800 --> 00:05:13,080
apareceram foram. 
Melhorar a qualidade geral do 

94
00:05:13,080 --> 00:05:17,320
código deixá lo mais limpo, mais
fácil de dar manutenção no 

95
00:05:17,320 --> 00:05:19,600
futuro. 
E também a questão de sugerir 

96
00:05:19,600 --> 00:05:22,920
soluções alternativas, às vezes 
o revisor tem uma ideia 

97
00:05:22,920 --> 00:05:26,120
diferente sobre o design ou 
conhece um algoritmo que seria 

98
00:05:26,120 --> 00:05:28,880
mais adequado ali. 
E teve mais um ponto que me 

99
00:05:28,880 --> 00:05:31,560
chamou. 
Atenção. 

100
00:05:31,560 --> 00:05:34,840
Essa mesma transferência de 
conhecimento. 

101
00:05:35,000 --> 00:05:39,000
Como isso funciona na revisão? 
Ah, isso é fantástico e às vezes

102
00:05:39,000 --> 00:05:42,800
subestimado. 
A revisão é uma via de mão dupla

103
00:05:42,800 --> 00:05:46,280
para aprender. 
O autor do código aprende com 

104
00:05:46,280 --> 00:05:50,440
experiência com as sugestões do 
revisor, e o revisor também 

105
00:05:50,440 --> 00:05:55,000
aprende e se dispõe a novas 
formas de resolver problemas a 

106
00:05:55,000 --> 00:05:57,240
lógicas diferentes que o autor 
criou. 

107
00:05:57,720 --> 00:06:00,360
Entende melhor as outras partes 
do sistema. 

108
00:06:00,600 --> 00:06:03,880
E isso é interessante, ajuda a 
quebrar aquelas ilhas de 

109
00:06:03,880 --> 00:06:06,960
conhecimento que às vezes se 
formam nos times, né, onde só 

110
00:06:06,960 --> 00:06:09,440
uma pessoa sabe mexer numa parte
crítica. 

111
00:06:09,440 --> 00:06:12,840
Exatamente. 
Esse é um ponto crucial, quanto 

112
00:06:12,840 --> 00:06:16,880
mais gente entende mais partes 
do código, o time todo fica mais

113
00:06:16,880 --> 00:06:20,480
forte, fica mais fácil cobrir 
férias, lidar com a saída de 

114
00:06:20,480 --> 00:06:21,640
alguém. 
Entendi. 

115
00:06:21,640 --> 00:06:25,160
Claro que exige um esforço, né? 
Parar o que você está fazendo 

116
00:06:25,160 --> 00:06:29,200
para ler e entender o código do 
colega na correria do dia a dia 

117
00:06:29,200 --> 00:06:33,720
nem sempre é fácil, mas o ganho 
em colaboração, em aprendizado 

118
00:06:33,720 --> 00:06:38,640
mútuo e na responsabilidade 
compartilhada pela qualidade a 

119
00:06:38,640 --> 00:06:42,840
isso é enorme. 
Bom, a importância ficou clara, 

120
00:06:42,840 --> 00:06:45,440
tanto pra qualidade do código 
quanto pro time. 

121
00:06:45,800 --> 00:06:49,280
Mas vamos pra prática. 
O revisor abriu lá o Pure Quest.

122
00:06:49,480 --> 00:06:51,600
O que ele deve procurar? 
Pra onde ele olha? 

123
00:06:51,600 --> 00:06:56,080
Primeiro é só sair caçando bug. 
Caçar bug é parte importante, 

124
00:06:56,120 --> 00:07:00,040
mas tem bem mais coisa no radar.
O material até traz uma lista 

125
00:07:00,040 --> 00:07:02,000
bem extensa de pontos pra 
observar. 

126
00:07:02,360 --> 00:07:04,240
A gente pode agrupar pra ficar 
mais fácil. 

127
00:07:04,560 --> 00:07:07,520
Um primeiro grupo seria assim, 
correção e robustez. 

128
00:07:07,800 --> 00:07:11,400
Aí entram os bugs, óbvios, 
claro, mas também coisas como o 

129
00:07:11,400 --> 00:07:15,360
tratamento de erro que ficou 
faltando ou que tá inadequado, e

130
00:07:15,360 --> 00:07:19,200
também questões de segurança, 
privacidade, vulnerabilidades 

131
00:07:19,200 --> 00:07:21,000
que possam ter sido 
introduzidas. 

132
00:07:21,200 --> 00:07:24,880
Ok, o básico da funcionalidade e
segurança, que mais? 

133
00:07:25,160 --> 00:07:28,880
Outro grupo super importante é 
design e arquitetura. 

134
00:07:29,240 --> 00:07:32,040
Aqui, o revisor precisa ter um 
olhar mais crítico sobre a 

135
00:07:32,040 --> 00:07:36,760
estrutura do código, tipo, tipo,
complexidade, que não precisava 

136
00:07:36,760 --> 00:07:40,280
existir. 
Sabe código muito complicado 

137
00:07:40,280 --> 00:07:45,080
para resolver algo simples ou o 
uso de algoritmos e estruturas 

138
00:07:45,080 --> 00:07:47,840
de dados que talvez não sejam os
melhores para aquele problema 

139
00:07:47,840 --> 00:07:51,440
específico. 
Também entra aqui verificar se o

140
00:07:51,440 --> 00:07:54,600
código está seguindo os 
princípios de design adotados 

141
00:07:54,600 --> 00:07:58,800
pela equipe tipo solid. 
Sabe aqueles princípios para 

142
00:07:58,800 --> 00:08:01,800
deixar o código mais flexível, 
mais fácil de mudar? 

143
00:08:02,240 --> 00:08:05,280
E se não está violando a 
arquitetura geral do sistema. 

144
00:08:05,520 --> 00:08:08,040
Por exemplo, misturando coisas 
que deveriam estar em camadas 

145
00:08:08,040 --> 00:08:13,120
diferentes e os famosos cold 
mels, aqueles cheirinhos no 

146
00:08:13,120 --> 00:08:16,880
código que indicam que algo pode
não estar legal no design. 

147
00:08:17,360 --> 00:08:30,640
Certo, e além de correção e. 
Design, verificar se tem testes 

148
00:08:30,640 --> 00:08:33,840
automatizados para o código novo
ou alterado. 

149
00:08:34,360 --> 00:08:38,600
Se a documentação essencial tá 
lá, se o código tá bem 

150
00:08:38,600 --> 00:08:42,799
formatado, indentação certinha, 
espaçamento consistente e se os 

151
00:08:42,799 --> 00:08:47,160
nomes das coisas, variáveis, 
métodos, classes são claros e 

152
00:08:47,160 --> 00:08:50,400
seguem o padrão do projeto 
código difícil de ler é um 

153
00:08:50,440 --> 00:09:00,440
pesadelo pra manter. 
Tem que ficar de olho se não tem

154
00:09:00,440 --> 00:09:04,400
otimizações feitas cedo demais. 
Sabe aquelas que complicam o 

155
00:09:04,400 --> 00:09:07,200
código sem um ganho real 
comprovado? 

156
00:09:07,200 --> 00:09:10,960
Otimização prematura, né? 
Isso, mas também o contrário. 

157
00:09:11,280 --> 00:09:15,240
Problemas reais de performance 
que podem ter sido criados, uso 

158
00:09:15,240 --> 00:09:19,400
ineficiente de APIs, consumo 
Exagerado de memória, problemas 

159
00:09:19,400 --> 00:09:21,840
de concorrência. 
Essas coisas podem ser bem 

160
00:09:21,840 --> 00:09:24,240
chatas de achar depois que o 
código tá em produção. 

161
00:09:24,240 --> 00:09:27,320
Entendi. 
E, por fim, um ponto mais, 

162
00:09:27,320 --> 00:09:31,640
digamos, administrativo. 
Conformidade, o revisor também 

163
00:09:31,640 --> 00:09:35,200
tem que checar se o código tá 
usando só as bibliotecas, as 

164
00:09:35,200 --> 00:09:39,120
ferramentas que são permitidas 
no projeto ou pela empresa. 

165
00:09:39,360 --> 00:09:44,040
Uau, realmente é. 
É uma lista bem completa. 

166
00:09:44,040 --> 00:09:47,680
Cobre muita coisa, né? 
De certa forma, quase todo o 

167
00:09:47,680 --> 00:09:51,880
ciclo de vida do software tá aí.
Sim, é um checklist bem 

168
00:09:51,880 --> 00:09:55,320
abrangente. 
Tá bom sabendo o que procurar, a

169
00:09:55,320 --> 00:09:58,720
próxima pergunta é, como dar 
esse feedback? 

170
00:09:59,120 --> 00:10:02,360
Como ser um bom revisor? 
O artigo também dá umas dicas 

171
00:10:02,360 --> 00:10:06,240
bem práticas para isso, baseadas
em pesquisas com PR de verdade. 

172
00:10:06,800 --> 00:10:10,680
Vamos começar com as dicas mais 
gerais, uma que achei importante

173
00:10:11,000 --> 00:10:14,600
focar em problemas objetivos 
claros, evitar aquele 

174
00:10:14,600 --> 00:10:16,800
comentário, Ah, eu faria 
diferente. 

175
00:10:16,960 --> 00:10:20,680
Sim, isso é péssimo. 
A ideia não é impor o seu estilo

176
00:10:20,680 --> 00:10:24,360
pessoal, sugerir uma alternativa
só se ela for tipo 

177
00:10:24,360 --> 00:10:27,760
inequivocamente melhor. 
Se trouxer um ganho técnico 

178
00:10:27,760 --> 00:10:31,440
claro ou se alinhar melhor com o
padrão que já existe no projeto?

179
00:10:31,520 --> 00:10:34,840
Exatamente. 
E nessa linha, evitar aquelas 

180
00:10:34,840 --> 00:10:38,040
discussões que não acabam mais 
sobre estilo pessoal. 

181
00:10:38,440 --> 00:10:44,120
Tipo, se a variável de um loop 
chama i ou index, a menos que o 

182
00:10:44,120 --> 00:10:47,200
estilo esteja tão ruim que 
realmente atrapalhe muito a 

183
00:10:47,200 --> 00:10:49,840
leitura, é melhor focar em 
outras coisas. 

184
00:10:50,080 --> 00:10:54,280
O importante é a funcionalidade,
a correção, o design, a 

185
00:10:54,280 --> 00:10:57,240
manutensibilidade. 
E a forma de falar, né? 

186
00:10:57,760 --> 00:11:01,200
O artigo bate muito na tecla de 
ser sempre educado, 

187
00:11:01,360 --> 00:11:03,640
profissional. 
Fundamental. 

188
00:11:03,720 --> 00:11:07,000
Nada de sarcasmo, de ironia, de 
ser grosso. 

189
00:11:07,280 --> 00:11:10,760
A comunicação tem que ser 
construtiva e manter o foco no 

190
00:11:10,760 --> 00:11:14,760
código que tá sendo revisado. 
Não trazer outras discussões, 

191
00:11:14,920 --> 00:11:17,320
críticas pessoais para a 
conversa do PR. 

192
00:11:17,640 --> 00:11:21,960
Com certeza é bom sempre 
lembrar, o objetivo é melhorar o

193
00:11:21,960 --> 00:11:26,360
código, melhorar o produto. 
Não é uma avaliação do colega, 

194
00:11:26,600 --> 00:11:30,840
não é para diminuir ninguém. 
É um trabalho de time e o jeito 

195
00:11:30,840 --> 00:11:34,720
de dar o feedback afeta tudo. 
A receptividade, o clima da 

196
00:11:34,720 --> 00:11:36,080
equipe. 
Totalmente. 

197
00:11:36,560 --> 00:11:40,880
E além dessas bases de educação 
e foco, o artigo traz umas 

198
00:11:40,880 --> 00:11:44,360
recomendações bem específicas, 
umas dicas práticas que eu achei

199
00:11:44,360 --> 00:11:47,840
bem legais. 
Por exemplo, eles sugerem fazer 

200
00:11:47,840 --> 00:11:51,080
perguntas em vez de fazer 
afirmações muito diretas. 

201
00:11:51,080 --> 00:11:52,920
Muitos julgadores. 
Como assim? 

202
00:11:53,160 --> 00:11:55,560
Em vez de dizer. 
Esse código aqui não serve para 

203
00:11:55,560 --> 00:12:00,040
nada perguntar algo como essa 
variável ainda está sendo usada 

204
00:12:00,040 --> 00:12:03,400
em algum lugar ou qual que é o 
caso de uso para essa função? 

205
00:12:04,040 --> 00:12:08,000
Isso soa menos acusatório, né? 
Abre mais espaço para conversa. 

206
00:12:08,080 --> 00:12:11,280
Ah, sim, faz sentido, é mais 
convidativo o diálogo. 

207
00:12:11,400 --> 00:12:15,200
Outra dica que achei ótima, se 
você, como revisor, fez um 

208
00:12:15,200 --> 00:12:18,400
comentário e depois percebeu que
estava enganado com a resposta 

209
00:12:18,400 --> 00:12:22,240
do autor, reconheça o erro. 
Humildade é importante. 

210
00:12:22,240 --> 00:12:24,520
Sim. 
Um simples OPA. 

211
00:12:24,600 --> 00:12:26,440
Verdade. 
Não tinha pensado nisso. 

212
00:12:26,680 --> 00:12:28,760
Entendi. 
Agora, obrigado pela explicação.

213
00:12:28,960 --> 00:12:31,920
Já mostra profissionalismo e 
ajuda a conversa a seguir num 

214
00:12:31,920 --> 00:12:33,480
bom caminho. 
Legal o. 

215
00:12:33,480 --> 00:12:37,480
Uso de emojis também é citado 
para dar uma suavisada no tom, 

216
00:12:37,520 --> 00:12:41,640
deixar a comunicação menos seca,
mas, claro, com moderação, né? 

217
00:12:42,040 --> 00:12:43,800
Depende muito da cultura do 
time. 

218
00:12:44,000 --> 00:12:48,160
Sim, tem que ter bom senso. 
Outra prática excelente que o 

219
00:12:48,160 --> 00:12:51,000
artigo menciona é referenciar a 
documentação. 

220
00:12:51,000 --> 00:12:53,920
A isso é bom? 
Se você está sugerindo algo e 

221
00:12:53,920 --> 00:12:57,440
tem um artigo, um post de blog 
ou mesmo a documentação interna 

222
00:12:57,440 --> 00:13:01,160
do projeto que explica porque 
que aquilo é bom, coloque o link

223
00:13:01,360 --> 00:13:06,080
mostra que não é só uma opinião 
sua, tipo, olha, talvez usar a 

224
00:13:06,080 --> 00:13:09,880
função x aqui seja melhor. 
Ela já faz essa validação está 

225
00:13:09,880 --> 00:13:12,200
descrito aqui na nossa wic, ó 
link. 

226
00:13:12,680 --> 00:13:15,920
Fundamenta a sugestão. 
E uma coisa que às vezes a gente

227
00:13:15,920 --> 00:13:19,840
esquece no meio da busca por 
problemas, elogiar. 

228
00:13:20,000 --> 00:13:22,120
Ah, isso é tão importante. 
Né? 

229
00:13:22,400 --> 00:13:26,000
Seu ator fez um trabalho bacana,
escreveu testes super claros 

230
00:13:26,200 --> 00:13:28,160
achou uma solução elegante para 
um problema? 

231
00:13:28,160 --> 00:13:32,120
Difícil reconheça isso, um 
comentário tipo nossa, que 

232
00:13:32,120 --> 00:13:35,040
cobertura de testes legal aqui. 
Eu adorei o jeito que você 

233
00:13:35,040 --> 00:13:38,240
resolveu, isso motiva muito. 
Com certeza. 

234
00:13:38,520 --> 00:13:43,280
E o uso de imagens? 
Screenshots o artigo fala disso 

235
00:13:43,280 --> 00:13:44,520
também. 
Fala sim. 

236
00:13:44,760 --> 00:13:47,720
Citar um exemplo onde o revisor 
tirou um print da tela pra 

237
00:13:47,720 --> 00:13:50,720
mostrar um bug visual que o 
código tava causando num filtro 

238
00:13:50,720 --> 00:13:52,680
lá. 
Muito mais fácil do que tentar 

239
00:13:52,680 --> 00:13:54,520
descrever o problema só com o 
texto, né? 

240
00:13:54,520 --> 00:13:59,360
Vai direto ao ponto. 
Verdade e justificar sugestões? 

241
00:13:59,360 --> 00:14:01,600
Também. 
Especialmente se o autor for 

242
00:14:01,600 --> 00:14:05,160
mais novo na equipe ou se o 
motivo da sugestão não for tão 

243
00:14:05,160 --> 00:14:07,480
óbvio. 
O exemplo que eles dão é sugerir

244
00:14:07,480 --> 00:14:10,960
trocar uma estrutura de dados 
tipo um r list por um hashmap. 

245
00:14:11,520 --> 00:14:14,960
Não basta só dizer troca, é bom 
explicar porque aquilo seria 

246
00:14:14,960 --> 00:14:18,040
melhor naquele contexto. 
Olha, com o rachmap, a busca 

247
00:14:18,040 --> 00:14:20,680
aqui vai ficar bem mais rápida 
por causa disso e disso. 

248
00:14:20,680 --> 00:14:23,680
E tem uma dica de linguagem 
interessante também, né? 

249
00:14:23,840 --> 00:14:26,600
Sobre usar nós, agente? 
Sim. 

250
00:14:26,800 --> 00:14:30,560
Em vez de focar no você usar uma
linguagem mais colaborativa, 

251
00:14:30,840 --> 00:14:33,640
perguntar, será que a gente não 
conseguiria simplificar essa 

252
00:14:33,640 --> 00:14:36,680
lógica? 
Aqui só é diferente de você não 

253
00:14:36,680 --> 00:14:38,520
consegue simplificar essa 
lógica. 

254
00:14:38,760 --> 00:14:40,720
Reforça que o cólogo é do time 
todo. 

255
00:14:40,720 --> 00:14:44,320
Boa e para fechar as dicas para 
os revisores, o que fazer quando

256
00:14:44,320 --> 00:14:47,160
a discussão impaca? 
Ah, essa é a dica final. 

257
00:14:47,800 --> 00:14:50,720
Se um ponto específico tá 
gerando muita discordância, a 

258
00:14:50,720 --> 00:14:52,960
troca de comentários no PR não 
tá andando. 

259
00:14:53,280 --> 00:14:56,320
A sugestão é propor uma conversa
rápida ao vivo. 

260
00:14:56,360 --> 00:15:00,560
Sair do assíncrono. 
Isso uma chamada de vídeo curta 

261
00:15:00,560 --> 00:15:03,800
para alinhar os ponteiros. 
Mas o artigo frisa, aqui isso 

262
00:15:03,800 --> 00:15:05,520
deve ser A Exceção. 
Não há regra. 

263
00:15:05,840 --> 00:15:08,200
Se não perde a vantagem da 
comunicação assíncrona. 

264
00:15:08,440 --> 00:15:10,680
Que permite que cada um revise 
no seu tempo. 

265
00:15:10,880 --> 00:15:13,840
Entendido? 
Boas dicas para os revisores. 

266
00:15:14,040 --> 00:15:18,240
Ok, falamos bastante de quem 
revisa, mas e a outra ponta, a 

267
00:15:18,240 --> 00:15:21,320
pessoa que escreveu o código, 
que está recebendo esse Monte de

268
00:15:21,320 --> 00:15:23,680
feedback, o que é importante 
para ela? 

269
00:15:23,840 --> 00:15:26,760
Bom, as dicas para os autores 
vão muito na linha da 

270
00:15:26,760 --> 00:15:30,560
comunicação também, manter o 
profissionalismo, responder de 

271
00:15:30,560 --> 00:15:32,960
forma educada. 
A mesma base, né? 

272
00:15:32,960 --> 00:15:35,520
Sim. 
E talvez o ponto mais crucial 

273
00:15:35,520 --> 00:15:38,560
seja. 
Não levar para o lado pessoal. 

274
00:15:38,640 --> 00:15:42,960
Sério, é muito fácil sentir que 
estão criticando você, sua 

275
00:15:42,960 --> 00:15:47,240
capacidade, mas tem que lembrar.
A revisão é sobre o código. 

276
00:15:47,400 --> 00:15:50,120
O objetivo é melhorar o produto 
final juntos. 

277
00:15:50,240 --> 00:15:53,320
E tem uma dica super hepática 
para os autores que o artigo 

278
00:15:53,320 --> 00:15:57,200
martela bastante e que faz uma 
diferença brutal para o processo

279
00:15:57,200 --> 00:16:01,960
todo funcionar bem, submeter 
Pure Quest pequenos. 

280
00:16:02,040 --> 00:16:04,600
A essa é clássica. 
Essencial. 

281
00:16:04,960 --> 00:16:09,680
Revisar um piar gigante com 
centenas, milhares de linhas é 

282
00:16:09,680 --> 00:16:13,240
humanamente impossível. 
Fazer direito cansa a atenção. 

283
00:16:13,240 --> 00:16:17,360
Se perde um Monte de coisa, 
passa batido o livro software de

284
00:16:17,360 --> 00:16:20,840
nearing at Google. 
Até recomendo um limite, algo em

285
00:16:20,840 --> 00:16:24,000
torno de 200 linhas por piar no 
máximo. 

286
00:16:24,080 --> 00:16:26,840
É verdade. 
Lembram de ter visto no artigo 

287
00:16:26,840 --> 00:16:30,440
aquela anedota que viralizou um 
tweet do reis Stanford? 

288
00:16:30,920 --> 00:16:34,280
Ele dizia algo tipo. 
Pede para alguém revisar 20 

289
00:16:34,280 --> 00:16:38,680
linhas, a pessoa acha 7 
problemas, pede para revisar 500

290
00:16:38,680 --> 00:16:43,000
linhas, ela acha zero problemas.
É um exagero, claro, mas tem um 

291
00:16:43,000 --> 00:16:47,800
fundo de verdade enorme. 
Total prs menores são muito mais

292
00:16:47,800 --> 00:16:51,760
fáceis de entender o contexto de
revisar com atenção, o feedback 

293
00:16:51,760 --> 00:16:54,760
tende a ser mais rápido, mais 
focado, mais útil. 

294
00:16:55,320 --> 00:16:59,720
Quem nunca abriu aquele PR 
monstruoso e pensou, meu Deus, 

295
00:16:59,720 --> 00:17:01,320
por onde eu começo? 
Pois é. 

296
00:17:01,680 --> 00:17:03,800
Facilita a vida de todo mundo. 
Exato. 

297
00:17:03,800 --> 00:17:07,560
E conectando tudo isso, é 
importante lembrar que nem toda 

298
00:17:07,560 --> 00:17:11,319
essa checagem precisa ser feita 
manualmente pelos olhos do 

299
00:17:11,319 --> 00:17:14,720
revisor humano. 
Uma parte desse trabalho pode e 

300
00:17:14,720 --> 00:17:18,480
deve ser automatizada. 
Ah, bem lembrado, ferramentas. 

301
00:17:18,480 --> 00:17:22,880
Exato, ferramentas de análise 
estática, os famosos linters. 

302
00:17:23,160 --> 00:17:26,359
A gente pode configurar essas 
ferramentas no projeto para que 

303
00:17:26,359 --> 00:17:29,840
elas verifiquem automaticamente 
um Monte de regras. 

304
00:17:29,840 --> 00:17:32,360
Que tipo de regras? 
Coisas como padrões de 

305
00:17:32,360 --> 00:17:35,920
nomenclatura, se todo mundo está
seguindo as mesmas convenções 

306
00:17:35,920 --> 00:17:40,680
para nomear variáveis funções, o
estilo de formatação do código 

307
00:17:40,880 --> 00:17:44,080
se usa tab ao espaço onde vai a 
chave. 

308
00:17:44,120 --> 00:17:47,080
Aquelas discussões chatas que 
podem ser resolvidas por uma 

309
00:17:47,080 --> 00:17:49,600
ferramenta. 
Não é exatamente, e elas podem 

310
00:17:49,600 --> 00:17:52,000
até apontar alguns padrões de 
código. 

311
00:17:52,240 --> 00:17:56,560
Que são conhecidos por serem 
potencialmente problemáticos. 

312
00:17:56,760 --> 00:18:00,520
Entendi, e qual vantagem disso? 
A vantagem é liberar o tempo e a

313
00:18:00,520 --> 00:18:04,240
atenção do revisor humano, se a 
ferramenta já garante a 

314
00:18:04,240 --> 00:18:08,160
consistência do estilo, a 
formatação, essas coisas mais 

315
00:18:08,160 --> 00:18:10,960
superficiais, digamos assim. 
Embora importante pra 

316
00:18:10,960 --> 00:18:13,720
consistência. 
Sim, importantes, mas que não 

317
00:18:13,720 --> 00:18:17,760
exigem tanta análise crítica. 
Com isso resolvido, o revisor 

318
00:18:17,760 --> 00:18:20,360
pode focar no que realmente 
importa mais. 

319
00:18:20,720 --> 00:18:22,840
A lógica de negócio está 
correta? 

320
00:18:22,960 --> 00:18:27,120
O design da solução faz sentido?
Resolve bem o problema? 

321
00:18:27,160 --> 00:18:30,600
Tem algum bug mais escondido? 
Arquitetura está sendo 

322
00:18:30,600 --> 00:18:33,560
respeitada? 
São questões de maior valor 

323
00:18:33,560 --> 00:18:36,440
agregado. 
Faz todo o sentido deixar a 

324
00:18:36,440 --> 00:18:39,920
máquina fazer o trabalho 
repetitivo e o humano focar na 

325
00:18:39,920 --> 00:18:43,200
análise mais profunda. 
Bom, então pra gente ir 

326
00:18:43,200 --> 00:18:46,200
amarrando as pontas da nossa 
conversa de hoje ficou bem 

327
00:18:46,200 --> 00:18:48,920
claro, né? 
A revisão de código é muito mais

328
00:18:48,920 --> 00:18:51,120
do que só achar erro. 
Muito mais. 

329
00:18:51,160 --> 00:18:55,200
É uma prática chave para manter 
o código saudável a longo prazo.

330
00:18:55,320 --> 00:18:58,600
Para melhorar a qualidade? 
Sim, mas talvez o maior valor 

331
00:18:58,600 --> 00:19:02,200
esteja mesmo na colaboração que 
ela gera e principalmente, como 

332
00:19:02,200 --> 00:19:05,160
você bem destacou, na partilha 
de conhecimento dentro da 

333
00:19:05,160 --> 00:19:07,360
equipe. 
Isso vemos como o processo 

334
00:19:07,360 --> 00:19:10,440
geralmente funciona na prática 
com os Pure Quest. 

335
00:19:10,840 --> 00:19:13,480
Demos uma olhada na extensa 
lista do que um revisor pode 

336
00:19:13,480 --> 00:19:18,160
observar de bugs, a design de 
performance e a legibilidade e 

337
00:19:18,160 --> 00:19:21,680
passamos por dicas bem práticas,
tanto para quem revisa quanto 

338
00:19:21,680 --> 00:19:25,120
para quem é revisado com aquela 
regra de ouro que, vale repetir,

339
00:19:25,400 --> 00:19:28,840
mantenham os prs pequenos. 
Facilita tudo. 

340
00:19:28,920 --> 00:19:31,560
Sem dúvida. 
Acho que o principal é mudar a 

341
00:19:31,560 --> 00:19:34,960
mentalidade, sabe? 
Não encarar a revisão como uma 

342
00:19:34,960 --> 00:19:39,320
crítica pessoal, mas como uma 
chance de aprender, de ensinar. 

343
00:19:39,640 --> 00:19:43,520
De construir algo melhor juntos.
Quando a equipe abraça a revisão

344
00:19:43,520 --> 00:19:47,600
com esse espírito, ele vira um 
investimento poderoso na 

345
00:19:47,600 --> 00:19:50,560
qualidade do software e no 
crescimento de todo mundo. 

346
00:19:50,720 --> 00:19:54,080
Perfeito. 
O feedback construtivo, quando 

347
00:19:54,080 --> 00:19:57,480
bem feito e bem recebido, 
realmente impulsiona o time pra 

348
00:19:57,480 --> 00:19:59,920
frente. 
Bom, muito obrigado por essa 

349
00:19:59,920 --> 00:20:03,000
conversa esclarecedora sobre 
revisão de código. 

350
00:20:03,360 --> 00:20:07,480
Foi ótimo explorar esses pontos.
Eu que agradeço o convite foi um

351
00:20:07,480 --> 00:20:09,840
papo muito bacana. 
E obrigado a você que nos 

352
00:20:09,840 --> 00:20:13,520
acompanhou em mais essa análise 
detalhada até a nossa próxima 

353
00:20:13,520 --> 00:20:14,280
exploração.