Latest / Entre Chaves / #267 Architecture Decision Records para eliminar a amnésia arquitetural

Transcript

#267 Architecture Decision Records para eliminar a amnésia arquitetural · Entre Chaves

0:03
Tá começando mais uma entre chaves, o seu podcast
0:06
desenvolvimento de software. Eu sou a Rafa e hoje vamos
0:09
começar com uma situação que eu acho que é muito comum na vida
0:12
de todo desenvolvedor, que é quando você precisa alterar um
0:15
código. Aí você encontra algo meio
0:17
confuso, meio estranho, uma solução que não é tão óbvia, e
0:21
aí você pergunta para o seu colega, para o seu teclead, por
0:24
que que a gente fez isso aqui? E aí ele fala, Ah, não sei, isso
0:28
aí é muito antigo, olha no slack, aí você olha no slack,
0:31
você não acha nada. E aí você roda um Git blame e aí
0:35
você vai ver OA mensagem do comit e é só um fixo.
0:39
E aí você encontra a pessoa que fez a alteração e ela saiu da
0:43
empresa há mais de 2 anos. E aí você se pergunta, por que
0:45
raios fizeram isso? Existe uma justificativa para
0:49
essa alteração? É ou isso aqui foi só alguma,
0:51
algum débito técnico que esqueceram?
0:53
Bom, essa situação é muito comum e ela é chamada de amnésia
0:57
arquitetural e ela acontece de forma inesperada.
1:00
Imagine que você tá ali, é com seu time numa cal, tomou uma
1:04
decisão que você mandou uma mensagem no slack, é pra decidir
1:08
alguma coisa com algum colega numa cal, rápida mensagem
1:11
privada, e aí com o tempo aquilo vai se perdendo e simplesmente
1:15
evaporou. O conhecimento não existe mais.
1:17
É, ficou só o resultado ali, a implementação.
1:20
E para resolver isso a gente tem uma prática chamada ADR, que é
1:24
arquitecture decision Record. E é uma forma, né, de registrar
1:29
não só a decisão tomada, mas o contexto daquela decisão, quais
1:33
foram as alternativas que foram consideradas e também a
1:37
justificativa para que uma determinada opção fosse
1:39
escolhida. E para falar sobre isso, hoje
1:41
estou aqui com o meu colega de bancada, Dudu.
1:44
E aí, rablo joia? Velho conhecido, né?
1:46
E também estamos com os 2. Convidados é desenvolvedores
1:49
aqui da DTI que estão lidando com a situação neste momento.
1:54
Para contar um pouco mais para gente que a Júlia é bem-vinda.
1:58
Tudo bem, e o? Sandro Renzo, então vamos lá, na
2:03
visão de vocês, quais são as dores reais que um time enfrenta
2:07
quando não há esse rastreio das decisões arquiteturais?
2:11
E aí, já fazendo um gancho, quais seriam os benefícios da
2:15
ADR para resolver este problema? Bom, Rafa, AO problema dessa
2:20
dessa falta assim de uma documentação específica para
2:24
essas decisões, é que igual você comentou assim na introdução, de
2:27
forma breve, tem essa questão da amnésia arquitetural.
2:30
Então, pelo fato da gente não ter muito bem documentado, às
2:34
vezes uma. Uma decisão de alguma
2:36
tecnologia, algum padrão de projeto que foi utilizado, acaba
2:40
que com a com a aplicação escalando, a gente acaba
2:45
enfrentando esses problemas, né? A gente assim é a questão do gap
2:50
técnico, que às vezes se tivesse uma coisa assim, mais uma piada
2:53
mais direcionada, a gente conseguiria dedicar um tempo ali
2:57
para o time para tirar dúvidas ali, dar uma olhada na
2:59
documentação e assim falando assim mais dos dessa solução.
3:05
É que a gente consegue também entender o contexto do porque
3:08
Ela Foi implementada. Então é muito assim,
3:11
considerando um time que maioria dos desenvolvedores preferem a
3:15
tecnologia react ao invés de usar 11 svelt, por exemplo.
3:21
Então a gente tomou como base a decisão desse desse
3:25
conhecimento, mais os desenvolvedores da tecnologia e
3:29
meio que solucionou esse essa esse problema dessa falta de
3:33
documentação, porque? Foi a decisão ali melhor do
3:35
contexto. O ponto não é só mostrar que
3:37
você escolheu x, né? E se o caminho ali que levou
3:41
essa decisão igual você falou a justificativa, né?
3:44
Que o time tem mais conhecimento nessa ferramenta.
3:46
E porque que não escolheu a outra coisa também, né?
3:48
E assim é muito do dos status mesmo dos ADRs.
3:52
Os ADRs, eles tem alguns status. Por exemplo, é o ADR que ele é
3:57
completo. Então, tipo assim, ele foi
3:59
discutido, foi levado em consideração, foi pensado os
4:02
prós, os contras, as alternativas também o porquê
4:05
dessas alternativas terem sido descartadas.
4:08
Assim, é bem um log mesmo, é bem uma pra evitar esse problema aí
4:12
de amnésia, arquitetural mesmo do de uma falta ali de uma
4:16
documentação que a gente vê que é uma coisa muito importante
4:19
assim hoje em dia, levando em consideração esse.
4:22
Esse avanço de a dessa, dessa integração da IA indedada no
4:26
código, esse tipo de coisa, isso facilita demais eu.
4:29
Fico lembrando, tipo assim, há 20 anos atrás, num num
4:32
desenvolvimento que eu tinha, teve um momento que eu tive que
4:34
fazer um comentário desse no código, olha, gente, não mexam
4:37
aqui. Eu sei que essa linha tá meio
4:39
maluca, mas por causa disso, disso, disso, eu botei lá o link
4:42
assim, olha, olhem essa documentação aqui desse bug.
4:45
Era um bug que tinha lá. Eu realmente tive que fazer um
4:47
if diz diferente de nu. Eu realmente vou fazer isso,
4:51
então, tipo assim, imagina um resolvedor?
4:55
É, tira o script, mas eu não vou falar a linguagem, é tipo assim,
4:58
era uma JVM específica que a gente usava na época lá nem era
5:03
oficial, então, tipo assim, tinha esse bug, imagina um
5:05
devolvedor chegando na lá e vendo cara, if diz igual a nu,
5:08
claro, claro que isso nunca vai ser nulo, diz.
5:11
Não pode ser nulo, ele vai tirar aquela linha, tudo começa a dar
5:14
problema, né? Só porque alguém falou, Ah, não
5:16
mexe aqui, o cara falou, Ah, o cara tava de brincadeira, né?
5:19
Numa época não tinha ADR, então a gente teve que deixar alguns
5:22
comentários, deixar muito bem claro ali naquele código, que
5:24
aquilo ali precisava ser mantido, né?
5:26
Mas corre aquele risco, às vezes alguém vai só rodar um script de
5:29
remover comentários do código, alguma coisa não fica tão tão
5:33
bem documentado. Então acho que, tipo assim,
5:35
talvez naquela época teria ajudado ao time do projeto, né,
5:38
se a gente tivesse uma alguma coisa assim, né, para poder
5:41
deixar essas decisões, né? Igual você, você até comentou,
5:43
né, que tem até tipo um fluxo de aprovação aparentemente para Dr,
5:48
né, que se você consegue. Começar e discutir?
5:50
Sim, Mano, sim. A gente consegue versionar essas
5:53
decisões mesmo. Por exemplo, a gente consegue
5:55
começar discussões dentro de Pure Quest.
5:58
Por exemplo, alguém tá iniciando 11 atividade de definir as as
6:04
decisões arquiteturais do projeto de um projeto x.
6:07
É, a gente consegue criar arquivos marckdown literalmente
6:11
ter documentado ali é seguindo a estrutura do do ADR, porque ele
6:15
tem uma estrutura muito fixa de. Título, status, descrição, as
6:20
alternativas. E assim dá para você versionar
6:22
isso e discutir com seus colegas de equipe, assim, entendendo a
6:26
preferência de cada um, entendendo ali porque é de um
6:29
gerenciador de estado x ao invés de um y, uma versão do do node x
6:34
ou ou outra, dá para ter essas discussões bem documentadas e
6:38
assim isso. Eu entendo que isso é muito bom
6:41
para o projeto, porque você consegue tanto direcionar o seu
6:45
projeto assim para esses recursos mais de e a esse tipo
6:48
de coisa, tanto para o seu estudo pessoal, para você
6:51
estudar ali uma versão específica, o porque de uma
6:54
versão x é diferente de y, esse tipo de coisa.
6:56
Porque OADR, você vai gerar um documento próprio, né?
6:59
Isso? E porque a gente faz isso
7:02
naquele documento? Ah, eu preciso desenvolver
7:05
alguma coisa. Eu vou botar aqui uma parte
7:07
aqui, uma feature nova que vai mexer com com filas e aí eu vou
7:11
escolher entre é serviços de mensageira, de de de Barramento
7:15
com garantia de entrega ou serviços de evento.
7:17
E aí eu tomo a decisão, cara, eu vou fazer evento ou eu vou fazer
7:20
fila? É por que isso deveria estar num
7:24
num ADR e não na especificação da história, por exemplo.
7:28
Eu Acredito que é. Exatamente.
7:30
Caso essa decisão depois seja questionada de algum jeito.
7:33
Por exemplo, a decisão que teria sido tomada nesse caso
7:36
apresentou um desempenho ruim ou alguma coisa desse tipo.
7:39
Só que está documentado lá que a outra seria pior por por tal
7:43
motivo. EOADR é um jeito de fazer um
7:46
template, né? Não é só explicar a situação
7:49
toda tem um contexto, tem a data, tem o status.
7:52
Seria lincado com a história, mas não necessariamente teria a
7:55
ver só com essa história. Não é necessariamente o que você
7:58
tem que fazer. Né?
7:59
É sim. Uma coisa que eu vi num artigo
8:01
que o Martin fala, ele escreveu sobre a Dr. Ele ele comenta algo
8:04
que eu acho que é muito subestimado, que é o benefício
8:07
da Dr nem é o documento em si, né?
8:09
O maior benefício nem é o documento em si, eSIM o ato de
8:13
escrever, porque você engaja o time.
8:16
AA ter discussão a ter um aprendizado ali sobre um
8:19
contexto que muitas vezes ele fica ali.
8:22
Só na cabeça do arquiteto, né? Então uma forma de você
8:24
democratizar isso e levar isso pra uma discussão ali, que é
8:28
algo às vezes que poderia levar horas de reunião, você resolve
8:31
ali no pow. Request ali nos comentários.
8:33
Então assim, é bem legal isso. E a reunião tem o negócio, que
8:37
nem sempre a reunião agravada por algum motivo e tem as
8:40
conversas rápidas, igual você comentou no privado que fica
8:44
documentado até a discussão. Várias vezes perguntou por que
8:46
que foi que a gente falou ali mesmo?
8:47
Tinham eram 4 itens. Eu só lembro de 3, né?
8:50
Geralmente umas coisas assim. Sim, sim.
8:52
Esse comentário brevemente sobre o template, né?
8:54
O? O.
8:55
Fala. Ele comenta que precisa ser
8:58
quase que uma seguir o mesmo princípio da matéria
9:01
jornalística, né? O que tá no topo é o mais
9:03
importante. E os detalhes?
9:05
Vem depois. Existe um template padrão?
9:08
Existe uma coisa que é ou depende, ou existem abordagens
9:12
diferentes ou vocês definem o template ou isso existe um
9:15
padrão, né? Um padrão.
9:17
Bom, Rafa, hoje sim tem uma template pros ADR. Geralmente o
9:21
ADR ele tem a questão do título é tem a questão do status dele,
9:25
se ele tá completo, se ele tá obsoleto, tem a questão da
9:28
descrição, né? De fato, as alternativas que
9:31
foram consideradas. E também tem a questão da
9:33
confiança. Se assim se o time ele tá 90% de
9:38
confiança de tomar aquela decisão e assim para auxiliar
9:43
essa essa definição, né? Da template tem algumas
9:46
extensões, por exemplo, no vers code, que é a Dr touss, a Dr
9:50
touss é uma extensão que ela vem para padronizar, é uma forma que
9:56
você definir assim é como se fosse um para não dispersar
9:59
assim muito de várias templates, várias estruturas, e ela vem
10:03
para. Padronizar mesmo ADR você
10:06
atualizar de forma mais fácil através assim de uma linha de
10:09
comando, facilitando ali mesmo a questão da da padronização da
10:14
utilização da ferramenta. Aí sai então um corpozão já todo
10:18
ali, uma redação do Enem pronta ou e tudo onde está as coisas
10:21
estão ali dentro o. OADR ele é bem para ser direto,
10:25
né? Assim não é para ser nada prolix
10:27
não é para ser nada complexo. É mais uma coisa assim.
10:30
Você colocar lá as alternativas, pai.
10:33
E principal. A decisão é essa.
10:34
A decisão é essa, o. Time vai depois.
10:37
É, o time vai revisando ou ou você tem uma confiança assim,
10:40
que por ser um time de poucas pessoas, várias pessoas saem em
10:43
contextos diferentes. Você decide tomar uma decisão
10:46
ali, você quer documentar aquilo.
10:48
Então é muito disso. É você ter essa esse log, né?
10:51
Essa essa parte assim no código versionada.
10:54
Pelo que a gente conversou antes do episódio de começar, eu sei
10:57
que vocês já vivenciaram, né? Um contexto em que vocês é,
11:00
tiveram um pouco dessas dores, viram a necessidade da Dr. E eu
11:03
queria que vocês contassem um pouco mais pra gente sobre.
11:05
A gente trabalha um projeto de sustentação, então são vários
11:09
produtos e todos, a maioria é de 2 anos para cima e todos a gente
11:15
chegou depois da conclusão do projeto.
11:17
Então a gente pegou igual você comentou que tem as decisões e o
11:21
resultado. A gente pegou só o resultado.
11:23
E tem bastante coisa que a gente precisa mexer, que não tá
11:27
funcionando, que acontece aquilo de quando tira, quebra por algum
11:30
motivo e até a gente entender porque que aquilo foi aplicado,
11:34
demora bastante, porque essas decisões, justamente por causa
11:37
disso, não foram documentadas. E não só de arquitetura, mas
11:40
trechos de códigos mesmo, então? A gente viu que se tivesse esse
11:45
template de documentação, estaria tudo organizado num
11:48
lugar só, porque o que tem geralmente é pequenos
11:50
comentários do código ou comentário de Pure Quest ou até
11:54
na especificação da história, que não fica tudo centralizado
11:57
num lugar só e num num jeito modular assim.
12:01
Quando vocês pegaram esse contexto aí e tudo que vocês
12:04
viram, que que OADR seria interessante.
12:06
Como que vocês decidem o que que vai para OADRO que que não vai
12:09
para OADR? Tipo assim, tudo vai para lá
12:11
tipo, Ah, não, gente, eu vou botar aqui, é?
12:13
E tentação de 2 tabs No No arquivo.
12:17
Sabe isso aí, não acho que isso não seria o um caso de uma Dr,
12:20
né? Ou tipo assim, Ah, vou usar, ou,
12:22
por exemplo, vou usar arquitetura em camadas, vou usar
12:24
cqrs, essas coisas acho que talvez possam virar uma Dr. Como
12:27
é que tem essa essa decisão, tipo assim, tudo vai?
12:31
Eu Acredito que tem que ir para uma Dr quando começa uma
12:34
discussão muito grande, então, por exemplo, a escolha da
12:37
arquitetura em si, arquitetura em camadas ou outra arquitetura.
12:41
Não precisaria isso fosse um consenso geral.
12:43
Então só uma documentação explicando essa arquitetura é
12:46
ok. Agora, quando tem uma discussão
12:48
muito grande de quais motivos para qual, aí eu acho que tem
12:51
que levar para esse tipo de documentação para entender.
12:54
Porque que houve uma? Discussão em primeiro lugar,
12:57
então, que nem você falou da identitação e seria mais para um
13:00
Deadline de de name de variável ou coisas assim e arquitetura?
13:05
Poderia ser só documentação. Então Eu Acredito que é quando
13:08
tem. Quando surge essa discussão
13:10
maior? Talvez, acrescentando, eu
13:13
colocaria também coisas que não são tão óbvias, coisas que
13:17
foram. Por exemplo, eu tenho uma tabela
13:21
que, sei lá, por algum motivo, ela ela tem a terceira forma
13:25
normal aplicada, mas por algum motivo ela tem uma coluna.
13:27
Que é redundante? E aí isso é parece trivial, mas
13:31
assim, se existe uma normalização naquela tabela, eu
13:34
eu vou questionar se eu ver uma duplicação e às vezes eu posso,
13:37
eu mesma, sem querer, remover uma duplicação e eu travar 11
13:41
consulta e essa consulta levar parar de funcionar, sei lá, por
13:44
conta disso, acho que coisas não óbvias, não triviais.
13:47
Eu acho que seria interessante. Coisas esquisitas, é.
13:49
Igual esse? If desigual.
13:52
Eu acho que esquisito, é a melhor.
13:53
Palavra é. Não necessariamente é ruim, mas
13:56
uma coisa é diferente do que tá no normal ali.
14:00
Que todo mundo tá acostumado a ver, né?
14:02
O que vai chamar atenção e falar, pera aí, tem tem um de
14:04
errado aqui? Não de errado, mas tem algo que
14:07
é um padrão que eu não reconheço.
14:09
O que é diferente de débito técnico, né?
14:11
Exatamente, exatamente. Um débito.
14:13
Você vai lá? Não, cara.
14:13
A gente sabe que isso aqui não é um código que tá tão bom e tal.
14:16
A gente entende algumas coisas assim.
14:18
EE vai, né? Mas é débito.
14:20
Técnico tem que ir pro tem que ir pro gira, né?
14:21
Exatamente. Principalmente porque dentro do
14:23
técnico você costuma achar nos nos nos acompanhamentos de
14:27
projeto, nessa gira azul e debops, ou o que é que seja?
14:29
Esqueci o nome desses sistemas, mas enfim, é algo assim.
14:32
Pessoal, o que que vocês consideram uma má prática de de
14:35
ADR? Ser prolix acho que a questão do
14:40
ADR você ser o mais claro e você ser o mais direto possível do
14:45
que você tá pensando. Pra justamente facilitar a
14:49
discussão e assim não não destoar muito do tópico mesmo,
14:55
levar a discussão pra aquela decisão daquela, por exemplo, de
14:59
uma tecnologia x tipo isso. Boa.
15:02
É tipo aquilo que eu comentei, tipo assim que eu perguntei, né?
15:05
Não é pra ser uma redação do Enem então, né?
15:07
Tipo assim, é só pra falar, cara, é isso?
15:09
É isso? Por causa disso?
15:10
Por causa disso, a confiança do time assim e foi considerado
15:14
pensando nisso, nisso e aquilo. Legal você ser direto, boa, acho
15:19
que é a base do ADR. Boa. Talvez seja um pouco abstrato,
15:22
mas é. Eu já lidei com uma situação em
15:24
que a gente teve um randover de um projeto, né?
15:27
Um time que absorveu um projeto de outro time e tinha 11 lista
15:33
de ADRs nesse projeto. Mas eu senti, sabe que faltou
15:37
detalhe de contexto, que tudo bem, é importante você não ser
15:40
prolixo. Mas é, você bate o olho ali e
15:44
você, beleza. Quer entender um pouco mais Oo
15:46
contexto daquela decisão? E aí não tem, só tem informações
15:50
que são são ali soltas. E eu senti que não foi muito
15:55
útil. Sabe que eu precisei de pegar um
15:56
contexto antes para entender o porquê que.
15:59
Aquela decisão foi necessária, que problema aconteceu que essa
16:03
decisão foi necessária, sabe? Então acho que é um trade off,
16:06
né? Você não pode ser prolixo, mas
16:08
eu acho que é legal você seguir essa pirâmide invertida e
16:10
colocando alguns detalhes, ou até você linkando um a Dr no
16:14
outro, né? Eu acho que isso é é uma prática
16:17
também e. Avaliando mesmo.
16:18
Eu acho que entendendo assim se vai criar uma nova discussão a
16:22
partir de uma Dr. Avaliar se aquilo compensa mesmo virar uma
16:27
Dr ou. Ou se descarta ou se vai para
16:30
uma guideline mais nesse sentido, facilitando mesmo as
16:33
discussões e não tornando aquilo uma coisa muito difícil de ler.
16:37
Algo muito complexo é ter esse Balanço mesmo, tanto da da
16:41
descrição, não tão assim, extremamente detalhada, mas não
16:45
algo tão tão simples, né? Legal.
16:48
Eu acho que entra muito aquilo que você falou, né, Júlia?
16:50
Tipo, cara, se algo não tá dando discussão, não tem porque ser
16:53
uma Dr também, sabe? Eu participei de um projeto
16:55
também, que o pessoal falou, Ah, não vamos discutir, fazer ADR,
16:58
então cada um do time ficou responsável por uma Dr, então
17:00
cada um ficava dentro daquele seu contexto e fazia aquilo, e
17:03
nas deles a gente só falava, Ah, ouvi essa parte, eles ouviram
17:06
tipo assim, mas fiz essa parte da Dr ou fiz essa Dr, não sei o
17:09
que tipo assim, depois que aquela pessoa tinha meio que
17:11
definido, aí ela chegava e pedia para o pessoal comentar alguma
17:14
coisa, geralmente o pessoal só Ah, ok, sabe, tipo então não
17:18
tinha discussão, era basicamente a definição arquitetural é que
17:21
virava tipo uma Dr para tudo, aí tinha um.
17:24
Cambada de ADR, lá Na Na lista do do Git.
17:27
É perde a motivação da Dr, que é documentar as decisões em grupo,
17:31
né? Não é só a pessoa fazer.
17:33
E às vezes, levando até essa questão da falta de contexto,
17:35
né, que a Rafa vivenciou, não tendo uma discussão ali, esse
17:38
tipo de coisa. Eu acho que muito da Dr é você
17:42
ser conciso e você levar a discussão.
17:45
Acho que é. Principal assim, é a base de
17:47
tudo. É, tá.
17:48
A gente já comentou sobre quem escreve, quem aprova, a gente
17:51
comentou sobre os PR. Mas e aí, como é que eu eu eu
17:54
garanto que isso não vire uma burocracia, porque eu acho que
17:57
talvez seja uma pergunta que os stakeholders faria se a gente
18:00
fosse começar AAA, usar ADR nos projetos.
18:04
Bom, Rafa, eu entendo que assim pra pra assim pra dar uma
18:09
balanceada nesse nessa questão do dessas burocracias e do.
18:13
No contexto, né? Do dia a dia ali do
18:15
desenvolvedor, eu tenderia mais ir pela parte de paralelizar o
18:20
seu trabalho. Então, por exemplo, você tá
18:23
pensando numa discussão, você conhece os seus colegas de
18:27
equipe? Então você levariam essa essa
18:30
discussão ao mesmo tempo que você vai desenvolvendo essas
18:33
tarefas, você vai atuando ali nessas atividades, não deixando
18:36
isso. Paralisar o seu, a sua sprint, o
18:40
seu ciclo, mas também não deixando isso de lado, tendo em
18:43
vista os prós que essa essa prática traz para gente.
18:47
Assim com o passar do tempo, né? Com a chegada de novos
18:51
desenvolvedores dessa questão da aplicação mudando, né?
18:54
Que às vezes nem sempre AA aplicação está toda mapeada.
18:58
A gente precisa de algum, alguma outra implementação que seja
19:02
algo nesse sentido? E aí é bom você ir documentando
19:06
as coisas assim por etapas. EE.
19:09
Assim é, é muito nesse nesse foco, assim de fazer essas 2
19:12
coisas. Entendi de entender o momento
19:15
certo, né? E tudo até para não ficar algo
19:16
muito engassado, né? Você falou?
19:18
Assim, sim, sim, sim. Ah, não tem que falar no
19:19
processo todo, toda especificação.
19:21
Tem que ter uma Dr pra essa decisão, alguma coisa assim.
19:24
É. É, eu acho que AIA também.
19:26
Ela reduziu muito essa essa Barreira.
19:28
É porque a hoje pra escrever é muito rápido, né?
19:31
O processo de escrita de você gerar.
19:34
Nesses a 10. Isso pode ser automatizado com
19:36
IA. Agora, uma coisa que a gente não
19:38
pode confundir é com os pack dreaming develop, né Dudu?
19:41
Com certeza. Isso aí eu acho que é uma coisa.
19:43
São coisas diferentes que a gente comentou lá no início, né?
19:44
A especificação, você vai falar o que você quer fazer aí?
19:48
Eu preciso fazer isso, eu preciso fazer aquilo.
19:50
Ah, vou, eu preciso implementar uma feature de fila que vai
19:53
botar lá usando post sub. E não é não, eventos.
20:00
Porque que eu vou usar isso no evento?
20:02
Vai estar numa ADR. É diferente da da da especificação.
20:05
Pelo menos da minha concepção, né?
20:06
Só estou falando bobagem. Vocês 2, por favor, podem falar.
20:10
Eu entendo que OADR ele vem pra complementar, tipo a um
20:14
adicional ao espec drib. Não sei se vocês têm a mesma
20:17
visão, caminho, mas com definições mais claras.
20:20
Com toda essa discussão, eu acho que é é algo para enriquecer,
20:25
enriquecer o contexto da IA. Dá pra dá pra você?
20:30
É ali, na fase de de criar spec, você adicionar como contexto
20:36
aquele arquivo macdown daquele é DRE, ter assim uma especificação
20:41
mais clara assim pra pra você gerar um pleno ali, mais fácil
20:44
que aí vai virar as tarefas, né? A implementação e com esse
20:48
contexto da Dr. Eu entendo que isso ajuda demais, né?
20:51
Você sempre dando mais contexto, sempre entendendo o que você
20:54
quer implementar, entra muito nessa pauta, entendeu você?
20:58
Com a discussão de outras pessoas, dá para considerar, por
21:01
exemplo, quando você entra ali na parte specie, né?
21:03
A Rafa mencionou do espec drib é geralmente a ideia.
21:07
Ela te faz algumas perguntas, ela faz perguntas melhores,
21:11
tendo em vista as decisões que foram.
21:13
Discutidas exatamente. Eu acho que é isso que você
21:15
falou, né, cara? É enriquecer o contexto com a Dr
21:19
de acordo com a necessidade dentro da especificação também,
21:22
não é tipo assim, todo a Dr tá lá dentro e julgar tudo ali
21:25
dentro do baldão também no contexto, não.
21:27
Da ya, porque senão vai ficar meio.
21:29
Maluca, vai ficar repetindo a arierra assim?
21:32
É do velho problema de engenharia de contexto lá que
21:35
provavelmente vamos estourar, né?
21:36
Exatamente. E vocês, tem algum alguma
21:40
sugestão de livro e material curso pra?
21:42
Bom, tem um artigo do Michael ninger.
21:47
Que tipo ele que padronizou essa ideia?
21:49
É até fácil de encontrar. É só jogar a Dr. Michael ninger
21:52
que você encontra isso fácil qualquer pesquisa, só um Google
21:56
e assim. Lá tem toda a motivação desse
21:59
estudo de dos contextos que ele vivenciou.
22:02
É, é um material assim que dá para você sumarizar.
22:05
Muito fácil, né? Com todo esse recurso que a
22:07
gente tem hoje em dia. Então é é um conteúdo assim
22:10
muito bom, que leva essas discussões, facilita às vezes
22:13
muito a vida de um desenvolvedor.
22:15
E eu acho assim, se fosse para recomendar, seria primariamente
22:19
esse esse artigo. Cara muito legal.
22:22
Acho que deu para entender, né? Recapitulando que a Dr é um
22:25
investimento. De baixíssimo esforço,
22:28
principalmente com o uso de ar. É e de alto impacto, né?
22:31
Na saúde dos times, para quem ninguém passe por aquela
22:34
situação que eu descrevi lá no começo, que é.
22:36
Acho que todo mundo aqui já vivenciou, ainda mais em times
22:39
de alta rotatividade, né? Então isso é muito frequente.
22:42
E aí eu deixo uma pergunta para nossa audiência, você já passou
22:46
por alguma situação engraçada que vocês?
22:48
Encontrar alguma coisa esquisita não fazia ideia do que de como
22:52
foi parar. E que tal começar hoje, né?
22:55
Legal essa ideia também de você pegar alguma, alguma, alguma
22:59
decisão que já teve no seu projeto e criar sua primeira Dr.
23:03
E aí, conta para gente nos comentários.
23:05
Como que foi isso? Foi fácil, né?
23:07
Se se realmente é tranquilo, EEO que que ajudou, né?
23:09
Tipo assim, o principal é isso, se você já usou, deixa para
23:12
gente também, é cara. Isso aqui ajudou bastante nisso,
23:15
daquilo. Como é que foi a experiência de
23:17
vocês? Isso, obrigada, pessoal,
23:19
obrigada e até a próxima. Valeu, pessoal.
23:21
Muito obrigado, tchau, tchau.