Latest / Entre Chaves / #272 Arquitetura de software: o que sobra quando a IA assume o código

Transcript

#272 Arquitetura de software: o que sobra quando a IA assume o código · Entre Chaves

0:00
Está começando mais um entre chaves, o seu podcast de
0:03
desenvolvimento de software. Meu nome é Luiz Fernando e eu
0:06
estou aqui hoje com você, ouvinte pra uma pergunta bem
0:09
simples e direta, a arquitetura de software morreu?
0:12
AEA matou a arquitetura de software.
0:15
Nós temos aqui 11 longa lista de argumentos pra gente poder
0:18
discutir prós, contras, quem está a favor, quem está
0:22
dissidente desse tão famoso tópico atualmente.
0:25
E tenho aqui, junto comigo a host, que todos vocês conheçam
0:28
em Fernanda. E aí, Luiz?
0:30
E aí, pessoal? Pois é, tô bem animada com esse
0:32
tema. A gente já falou muito aqui no
0:34
entre chaves, né? De Arns de papel, né?
0:38
Do desenvolvedor mudou. Só que hoje a gente vai olhar
0:40
para esse todo, esse arcabouço de um lado específico da
0:44
arquitetura de software, que eu tô bem, bem empolgada com esse
0:48
papo de hoje. Bora lá, temos aqui o Jeff com a
0:51
gente. Fala galera.
0:52
Já f aqui. E o Pedro aqui também, e aí?
0:55
Pessoal, tudo bom? Já pegando o gancho da
0:57
arquitetura de software, morreu. O que que é que a gente até hoje
1:01
aprendeu, entendeu? Estudou por décadas aí do que
1:04
era arquitetura de software. Bebendo aí nas Fontes do ancobob
1:08
do Eric Evans, né, que é o clássico do DDD, Martin Fowler,
1:12
tantos outros. E como é que a IA impacta?
1:16
O que a gente? Conhece como arquitetura?
1:18
Não, já começava falando. A arquitetura de software
1:21
morreu, já já começa um pouco difícil, mas o que a gente
1:23
aprendeu, pelo menos quando eu comecei a programar, 10 anos
1:26
atrás, quando eu comecei a desenvolver, é o arquiteto.
1:29
Era aquela pessoa que chegava com 80 páginas, cheio, 1000000
1:33
de coisas pra fazer, dava aquela série de requisitos e não
1:36
acompanhava o código. E uma das principais mudanças
1:38
que Eu Acredito que a IA vem trazendo é hoje.
1:41
Não existe ou não deve mais existir, sendo até polêmico, um
1:45
arquiteto que traz uma arquitetura e não acompanha a
1:48
evolução do código. Toda vez que o código tá
1:50
evoluindo, ele vem com a complexidade sintomática em cima
1:53
ou dentro dele. Então, o arquiteto hoje o papel
1:56
dele vai ser acompanhar também as decisões arquiteturais.
1:59
Qual o trade off que tá acontecendo dentro de cada
2:02
decisão e o que contribui para a evolução junto com AIA?
2:07
É no fundo assim, né? Quando a gente falava de
2:10
arquitetura, de software, a gente tinha um tanto de
2:12
conceitos aí no meio do caminho, né?
2:15
Que a gente falava de camadas, de inversão, de dependência de
2:19
mappers, de interfaces, de desacoplamentos, enfim, 1000000
2:24
de conceitos, né? Mexerica?
2:26
Assim, o Luís te apresentou como Pedro, mas a gente te conhece
2:29
muito aqui como mexerica, então vou usar a mexerica aqui no
2:32
episódio. Mas é o fato é que esses vários
2:35
e vários conceitos eram extremamente importantes pra
2:38
gente garantir que aquele código funcionava bem pra gente ler e
2:43
pra gente dar manutenção, né? Só que isso talvez tá gerando
2:47
complexidade pra ir atuar dentro dos nossos códigos, né?
2:51
Não só complexidade como custo, né?
2:54
Então é esse que é o negócio todo aqui desse episódio, né?
2:58
Eu concordo com muito que você falou Fernandinho, mas 11 coisa
3:01
que a gente tem que trazer? AEA aprendeu muito com papers de
3:05
mercado e papers pra arquitetura traz complexidade tudo que ela
3:09
traz é a eu quero usar DDD, será que vai realmente ser aplicar no
3:12
seu projeto eu quero usar 20 drive será que realmente vai se
3:16
aplicar no seu projeto criar que hoje é mais dependência e mais
3:21
burocracia do que um contexto isolado?
3:24
Microsserviços, eu tenho que começar com microsserviços ou
3:27
com. Um monolito da vida, o que que
3:30
vai me atender mais? E antes até trazendo o contexto
3:33
da IA e o que Eu Acredito que AA IA é uma principal potência no
3:37
sentido de hoje conseguimos executar as coisas mais rápido.
3:41
No passado, o arquiteto, ele tinha que fazer uma configuração
3:44
de uma gestão de arquitetura de 80 páginas.
3:47
Pegando um gancho que eu falei anteriormente, por quê?
3:50
Porque ele tinha aquele tempo pra fazer arquitetura e em
3:53
nenhum momento se ele não começasse com algo.
3:56
Que fosse escalável o suficiente, conseguiria ser
3:59
adequado. Hoje a gente vem atuando com
4:01
algo que com IA. Será que eu posso começar
4:04
pequeno e evoluindo gradativamente pra cada padrão,
4:07
pra cada coisa que atenda? A evolução da minha aplicação.
4:10
Tem um negócio muito interessante ali que o Jeff
4:12
falou em relação aos intervatos. Para mim é o é o exemplo mais
4:15
clássico assim, né? Que eu imagino que todos vocês
4:18
devem ter passado ou se não passar, não conhece alguém que
4:21
passou, que é basicamente aquele negócio assim, Ah, eu vou
4:23
colocar lá uma interface no meu repositório do com o meu banco,
4:27
por exemplo, que eu quero mudar a minha URM ou eu quero em algum
4:31
futuro distante. Eu preciso desacoplar tanto que
4:34
eu porque eu vou mudar o banco de dados, cara.
4:37
Assim, quantas pessoas você já conhece que precisaram de fato
4:41
mudar o banco de dados? EE, pra mim, assim, a gente
4:44
consegue fazer esse negócio muito mais simples, porque
4:47
refaturar é muito mais simples também.
4:49
Então você destrava umas coisas que antes, às vezes, não era
4:52
possível. Pô, eu vou colocar aqui a
4:54
interface. Porque eu quero, né, diminuir
4:57
esse risco no futuro, né? Quero mitigar esse problema de
5:00
no futuro, se eu precisar trocar, não está tudo acoplado.
5:03
E aí eu vou ter muito mais trabalho, só que agora e ela
5:06
tira, né? Esses riscos, ou pelo menos ela
5:09
diminui e a refaturação é infinitamente mais simples, ou
5:14
seja, você tem muito mais incentivo a começar mais
5:17
simples. Eu lembro a primeira vez que eu
5:20
propus arquitetura hexagonal. Pro cliente ele aprovou, até
5:24
hoje eu pago isso que a gente tá falando lá.
5:26
Quero fazer tal coisa, tenho que criar um case, fazer um
5:28
interfácil, implementar, trabalhar com DTO de request,
5:31
processar isso, fazer o Mac pra depois bater lá no meu banco com
5:35
A Entidade domínio converter, voltando nossa pra ter a
5:38
disponibilidade. Se eu precisar trocar o banco eu
5:40
só vou mexer aqui ó, nessa classe de repositor e que o
5:44
Regis to não precisou, não precisou trocar.
5:47
E ainda uma coisa muito importante pra gente falar
5:50
também hoje a ela lê texto, ela vai ler o código, ela tem um
5:55
conhecimento naquilo. Mas muito quando a gente fala de
5:58
de clean Arc, existe uma coisa, injeção de dependências, muita
6:02
injeção de dependência, vai acontecer em um time.
6:05
E se ela não leu, ela não entende.
6:07
Logo, ela não é eficaz quando ela tá atualizando, evoluindo o
6:11
meu. Código sim, tem até o dado aqui,
6:13
né? Dum paper foi publicado sobre o
6:15
cloud code. Que ele só consegue conseguir
6:19
identificar, em várias aplicações analisadas, 76% das
6:23
ligações com com gestão de dependência.
6:27
Então, a cada 4 vezes cada 4 tentativas do Cláudio cod um,
6:31
ele falhou. Justamente ele não conseguir
6:33
perceber essa conexão, né? Porque quando você tem injeção
6:36
de dependência, em vez de você ter o alto nível, dependendo do
6:40
baixo nível, os 2 dependem da abstração.
6:42
Só que isso só acontece em rentime igual você falou o como
6:45
essa ligação não existe no código OA IA não consegue
6:48
entender IA, você perde um dos princípios do iagni, né?
6:51
O iagner e o e o Wang go na meet, né?
6:53
Você não vai precisar disso. Um dos princípios do iagni é que
6:56
você nunca abstrai no primeiro uso, você abstrai no segundo.
6:59
Então assim, eu fiz uma coisa, Ah, eu acho que alguém precisar,
7:03
não importa, você não vai abstrair quando alguém precisar,
7:06
que segunda pessoa vai precisar daquilo ali.
7:09
Aí vocês traem? É justamente porque a gente
7:12
sempre acha que a gente, né? A gente sabe qual é a evolução
7:14
do projeto, mas a gente também sabe o quanto é complexo e o
7:18
quanto é, né? Mundo vuca muda o bane que a
7:21
gente vive no sentido assim. De que às vezes o negócio ele
7:24
até tá No No nosso road map mental muito em breve, só que às
7:29
vezes esse negócio nunca chega mesmo, então você querendo ou
7:32
não tá adicionando complexidade. E sabe uma coisa que é que é
7:34
interessante? Muitas vezes, o que você tem
7:36
medo? Ele realmente vai acontecer, mas
7:38
daqui a 3 anos. EE aí quando?
7:41
Você viver 3 anos com aquele negócio, né?
7:43
E quando? Você abstraiu lá atrás, há 3
7:44
anos atrás, sua situação era outra e muitas vezes a abstração
7:48
se referiu ali, não era exatamente o que era que vai
7:50
precisar. E vai mais te atrapalhar do que
7:53
te. Ajudar isso.
7:54
E aí, assim, o que acontecia? Assim é que você, poxa, eu vou
7:58
fazer a arquitetura mais perfeito.
8:00
Porque se eu chegar daqui 1 mês e falar, nossa, preciso
8:04
refaturar. Algumas pessoas olham refaturar
8:06
como algo assim, nossa, estou perdendo dinheiro.
8:09
Mas assim, se você faz mais simples, olha só esse exemplo,
8:13
você ficou 3 anos. Fazendo vários arquivos a mais,
8:16
quanto que você economizaria nesses 3 anos se.
8:19
Se colocar na ponta do lápis, né?
8:21
Pode ser que você já economizou só de ter feito mais simples no
8:24
início, né? E coia.
8:26
Quantos tokens você economizou? Coia hoje o que você tem, muito
8:30
menos arquivo e pasta para ler. Exatamente agora.
8:33
Esse esse assunto todo, gente de dos arquitetura do software,
8:36
morreu e tudo mais. Eu comecei a pensar nisso.
8:39
Foi justamente com você, Michele, que alguns meses atrás
8:42
que você falou assim comigo, olha, eu tô começando um projeto
8:44
aqui, mas eu tô começando com uma arquitetura extremamente
8:47
simples, porque eu acho que assim a ya vai até performar
8:50
melhor. E aí isso desbloqueou essa
8:53
discussão pra mim assim, e foram alguns meses atrás, né?
8:56
E assim, no final das contas, eu queria fazer essa pergunta pra
8:59
vocês agora que é? Estou começando um projeto novo,
9:04
então, se eu não tenho que fazer trazer os os conceitos de clinar
9:09
que ou trazer esses outros esses conceitos mais complexos, o que
9:12
que é mais importante que um arquiteto de software pense
9:15
quando ele agora tá começando um projeto novo só?
9:18
Antes de vocês responderem, vou pedir desculpa pelo início do
9:21
episódio que eu cogitei que a IA matou a arquitetura de software.
9:24
Foi o mixerica. Então me desculpa, foi o
9:27
mexerica. Quem matou a arquitetura de
9:29
software? É bom a gente ponderar alguns
9:31
pontos assim, a gente não está falando também pra gente remover
9:35
e remover todos os conceitos e vamos chamar tudo direto, todas
9:38
as camadas direto, et cetera. Como arquiteto, você avalia
9:41
várias, várias variáveis, né? Não só técnicas, mais
9:44
econômicas, tempo, et cetera, né?
9:46
Então é importante sempre que você for tomar as decisões, você
9:49
olhar várias variáveis, né? Inclusive em tempo, né?
9:52
É. Muito legal, né?
9:53
Eu estou. Estou reassistindo Dark.
9:54
E o passado sempre fala muito do futuro.
9:57
Só que a gente tem que reinventar o papel.
10:00
Anteriormente, principalmente por ser humano, o nosso vício
10:04
era nossa. Eu passei por 111, projeto muito
10:07
complexo que realmente eu tive que usar.
10:09
Esse parto aqui me ajudou. Então a tendência de iniciar um
10:13
projeto novo é não, já vou iniciar com isso.
10:16
E gerava essa abstração que o Luiz trouxe, que eu vou pagar
10:18
essa dívida por 3 anos, pra quando realmente eu precisasse
10:21
usar, o tempo seria menor, eu não vou carregar tanto tempo
10:25
desenvolvendo diante disso, a visão da arquitetura atual.
10:30
Que eu defenderia é se baseie nos princípios revisite o que
10:33
está aí também há muito tempo sendo dito, por exemplo, quem
10:36
sou eu, né? Mas Eu Acredito que o solid
10:38
chegou nos dias. A gente precisa mais daquela
10:40
sopa de letrinha inteira. A gente precisa saber bem os
10:44
princípios de injeção de dependência, mas.
10:47
O yagner vamos manter tudo simples.
10:49
Só quando chegar o segundo momento que eu vou pensar em
10:51
refaturar muitas coisas de clear, que é muito defor e que
10:55
aya vai executar bem porque Ela Foi treinada em cima desses
10:59
modelos, eu recomendo que eu utilize, mas isso a gente vai
11:01
conseguir com testes e também com o nível de maturidade e
11:05
eficiência, aí agora vinculando a ao harner, eu vou ter o guia
11:10
que vai ser. Se eu chegar hoje e dizer olha,
11:12
abri aqui, agora o Cláudio coloco lá o modo, o modo Tim,
11:15
que digo olha. Gostaria de começar um projeto,
11:17
vou começar com o micro serviço, ela tem uma viagem de
11:20
confirmação muito forte, mas é isso, vamos fazer com o micro
11:23
serviço aqui. Uma coisa que eu tô tentando
11:25
quebrar agora é, deixa eu desenhar essa solução, deixa eu
11:28
falar em voz alta, deixa eu ver se isso aqui realmente quantos
11:31
tokens eu vou gastar, quanto tempo eu vou levar para
11:34
implementar isso, o quanto que eu vou acumular de dívida
11:36
técnica é o que me faz seguir para uma arquitetura modular,
11:41
para um micro serviço, para um monolito.
11:44
Inclusive, antes da IA estourar a discussão era, para que micro
11:48
serviço? Todo mundo está tendenciando a
11:51
votar monolitos e agora acredito que está mais forte ainda.
11:54
Está para conversar bem acoplado, com tudo funcionando o
11:57
local e se necessário, a gente faz o módulo e escala.
12:01
É, você falou. Aí um ponto é a gente se atentar
12:05
ao conceito de fato, né? Pra pra que que existe arquiteto
12:09
e et cetera, né? Por exemplo, quando você vai
12:12
aplicar uma interface, et cetera, né, você quer na verdade
12:15
fazer um encapsulamento, fazer a modularização.
12:18
Então pensa no conceito, você pode ter seu né arquiteto e com
12:22
5 arquivos, 3 arquivos, né? Um arquivo da controler que seja
12:26
um arquivo lá de de serviço que vai encapsular regra de negócio
12:29
de repositório. Perfeito.
12:31
Se você quiser tirar o domínio, você coloca uma camada anti anti
12:35
corrupção para Oo domínio da API que você está chamando não ser
12:38
impactado, né? Pelo meio da aplicação.
12:40
Mas assim você conseguiu fazer a mesma coisa com menos arquivos,
12:44
né? Muitas vezes a gente.
12:45
Fazia mais pelo. Padrão do do do cliente por dar
12:48
continuidade. Todo mundo já conhece etcétera,
12:50
só que agora isso é tudo num tema muito importante.
12:52
O que a. Gente estava comentando no
12:53
começo que é a diferença entre. A teoria, os conceitos do que é
12:58
a arquitetura limpa, ODDDEO que é na prática, é como isso foi
13:02
sendo implementado ao longo do tempo.
13:03
Acho recai muito nisso aqui, porque se a gente parar pra
13:06
pensar nos conceitos, o que que é a parte importante, mesmo que
13:10
a gente não pode abrir mão. Primeiro é uma definição clara,
13:13
objetiva, bem feita, de modelo, com contextos pequenos, bem
13:17
definidos, bem subdivididos, tem uma linguagem umbíqua, bem
13:21
forte, bem estruturada e está realmente ligado com.
13:25
Um modelo de negócio e que é a definição clara dos limites.
13:27
Igual você acabou de falar, não vou ter minha API, eu vou ter
13:31
minha camada de negócio aqui que é meu domínio meio, vou ter uma
13:33
camada de infraestrutura aqui que vai ter o meu repositório,
13:36
minha persistência e tal. Tendo essas 3 coisas muito bem
13:40
definidas, como você vai implementar, aí já começa a
13:43
ficar fácil de variar. E, por exemplo, se a gente
13:45
mantém a linguagem ubíqua forte, presente na modelagem, presente
13:51
no seu projeto, você garante, Oo que você está implementando, tá?
13:55
Está alinhado com o negócio, está alinhado com o modelo, está
13:57
tudo ali permeando. Então acho que são os 3 pontos
14:01
que a gente não pode abrir mão. Isso me lembrou de testar uma
14:04
próximo item em um projeto que é um tema que vem se falando muito
14:07
divertical Slice esse modelo que a gente fala, né?
14:10
Controllers e case reposito e é bem usado sistemas de
14:13
informações em geral. Se você vai um pouquinho ali
14:16
para o lado em em jogos, né, você tem uns módulos mais auto
14:20
contidos por domínio, né? Por funcionalidades em si.
14:22
Então Eu Acredito que isso vai casar muito bem com AIA, porque.
14:26
Quando você está falando de autenticação, você quer dar um
14:28
contexto, etc, você arrasta a pasta de autenticação, ele só
14:32
precisa cuidar daquilo ali, não precisa tratar de de produto,
14:35
etc. Às vezes ele vai ler, né, por
14:37
proximidade, né? Ele vai ler coisa de produto, de
14:39
de carrinho, né? Se tratando de um ecommerce, né,
14:42
o vertical slife, eu acho que é um bom teste já a se fazer.
14:46
Sim, você diz que é basicamente assim, né?
14:48
É eu ter contextos muito bem definidos dentro do meu projeto.
14:52
Em que os contextos eles têm limites muito claros entre si e
14:57
a provavelmente AMLLM. Quando ela está construindo
15:00
sobre carrinho, ela não precisa saber sobre o usuário, é mais ou
15:03
menos. Isso, né?
15:05
Você normalmente na arquitetura mais comum que a gente tem, no,
15:08
no nexagonal, na clean arquitect.
15:10
O que que você faz? Você tem uma camada de API.
15:13
Por exemplo, dentro da API você você subdivide no seu modelo, no
15:17
meio você tem um projeto com uma camada de domínio.
15:21
Domínio, você sub divide igual eu IA falar carrinho, produto,
15:23
não sei o quê. Você tem um outro projeto
15:25
separado, que esse projeto é o de persistência de dados, e lá
15:29
se subdivide o vertical lá, se não isso tem um projeto único,
15:33
esse projeto único. Você põe uma pasta carrinho lá
15:36
dentro, dentro dessa pasta carrinho você tem.
15:39
O controle é da PI lá dentro, o outro arquivo, que é a regra de
15:41
negócio. Lá dentro do modelo, o outro
15:43
arquivo que é a persistência dele lá dentro.
15:45
Um projeto único com uma pasta. E está tudo dentro dessa pasta.
15:48
Você não tem as camadas. Separadas?
15:50
Que faz todo o sentido, né? Já que a gente o nosso principal
15:52
desafio com AIA ainda é o contexto, né?
15:55
E a gente conseguir filtrar o suficiente nosso contexto para
15:58
que AIA consiga ter o melhor, o contexto mais otimizado para
16:01
aquele momento, para atuar corretamente.
16:04
Parece que esse tipo de de arquitetura é que faz mais
16:06
sentido. É isso que o pessoal tem.
16:07
Tem alegado muito, que quando você trabalha trabalhando com
16:10
Oya e você tem o vertical sly, sim.
16:12
Você vira para Oya e fala, eu quero implementar alguma coisa
16:14
de produto. Ela vai dentro da pasta de
16:15
produto e tudo que ela quer está ali.
16:17
O máximo que ela vai olhar é uma pasta cherd que você colocou ali
16:20
fora, que tem alguma coisa comum.
16:22
É o máximo que ela vai olhar ali, mas ela vai olhar tudo que
16:24
ela precisa ali dentro. Teve um negócio que você falou
16:26
mais cedo, Jeff, em relação a ao harns, que eu acho que também é
16:30
um é interessante da gente. É falar um pouquinho, né?
16:34
Porque até agora a gente falou, bom, parece que esse vertical
16:36
Slice é uma boa possibilidade, né?
16:38
Outra coisa que vocês falaram é usar a base do clinark, mas
16:42
tendo muito, muita consciência do que aplicar, tirar as coisas
16:46
que realmente não precisam. Esperar a dor acontecer 2 vezes
16:50
para eu abstrair, né? São todos os conceitos aí que
16:53
vocês foram falando de coisas importantes que o arquiteto de
16:56
software hoje precisa, né? E eu queria te adicionar mais
16:59
uma coisa. Que é em relação ao harners
17:02
assim, e agora em relação aos Gates, né?
17:05
Porque no final das contas, Oo harners.
17:07
Ele tem muito a ver com os guias e os sensores, como você bem
17:09
falou. Mas se eu tenho sensores que por
17:12
exemplo é ficam validando a arquitetura do meu projeto, ou
17:16
seja, né, elas ficam validando os limites.
17:18
Se eu não a implementei uma regra de banco lá na camada de
17:23
apresentação, sei lá, e eu tenho esse tipo de teste automatizado
17:26
para ou eu tenho essa regra muito clara no meu sensor?
17:31
Eu já não. Talvez eu não precise tanto de
17:33
uma arquitetura tão verbosa para evitar esse tipo de coisa.
17:38
Né? Eu eu concordo 100% que você
17:40
falou, mas hoje talvez seja muito pelo menos o que eu tenho
17:44
vivenciado na DT é um pouco diferente.
17:46
É? Normalmente eu atuo em projetos
17:48
já existentes, então. É e esse é um.
17:50
Outro grande desafio, o que a gente tem feito de harners lá é
17:54
colocar guias bem definidos, então agora a gente tá correndo
17:57
atrás. Antes de começar o episódio, eu
17:59
tava conversando até com mexerica aqui a gente tava
18:02
trocando uma ideia no ponto de olha, agora a gente vai colocar
18:05
todas as decisões arquiteturais que a gente tomou, porque assim,
18:08
deixa eu dar um passo atrás. AI, AI, é muito funcionário do
18:11
mês, sabe? Ela vai dizer, olha, encontrei
18:13
essa divergência aqui, resolvi, tá, não, esse trade off eu tinha
18:17
tinha assumido há muito tempo. Então quando eu começo a trazer
18:20
para ela todas as decisões arquiteturais e as razões,
18:23
problemas que eu quis resolver e porque eu quero conviver com
18:26
aquilo. Até, por exemplo, olha, eu vou,
18:30
não vou trocar o banco de dados, então minha tabela de domínio,
18:32
eu vou acessar aquela informação ali direto mesmo, meu reposito,
18:36
ele vai bater lá, porque eu não vou trocar o banco.
18:38
Daqui a 3 anos, se virar um problema, essa misturação vai
18:41
ser simples de atuar, então você não precisa resolver isso.
18:44
Porém, isso vai conflitar diretamente com o guia.
18:47
Eu não posso ter 2 pesos, 2 medidas no meu sensor.
18:50
Dado que o meu guia é olha, siga o padrão do projeto para
18:54
realizar a construção de um novo módulo, ele vai entender que eu
18:58
tenho um módulo de vendas e agora eu quero fazer um módulo
19:00
de estoque. Ele vai se basear no módulo de
19:03
vendas para poder popular o meu módulo de estoque, dado que ele
19:07
começou a executar e agora tem uma divergência, e o meu sensor,
19:11
ele não vai ser efetivo. Então eu tenho que ter muito
19:15
claro a decisão atual. Olha, acabei de tomar uma
19:17
decisão. Essa aqui é minha Dr. Estou vai
19:20
acionando junto. Esse vai ser meu guia que vai
19:22
direcionar. A partir de agora, isso aqui
19:24
será o novo e eu vou voltar e faturar esse meu débito técnico.
19:27
E isso que você pegou é também uma coisa muito importante.
19:30
Não sei se algum de vocês já teve a chance de ler.
19:32
É um livro que eu li recentemente, chama arquitetura
19:34
de software. As as partes difíceis.
19:36
Os autores estavam escrevendo um livro sobre arquitetura de
19:39
software, um livro padrão normal, e aí eles foram pegando
19:42
vários exemplos de que eles viram na carreira deles.
19:45
E na hora eles iam tentar encaixar no livro, eles ficavam
19:47
assim, Ah, não está, está está complexo, está difícil, não, não
19:51
dá para explicar direito, jogava de lado.
19:53
Depois que eles terminaram o livro, eles olharam e falaram
19:55
assim, escreveram um livro sobre esses, esses projetos, esses
19:59
exemplos que eles largaram de lado, fizeram a pilha, por quê?
20:02
Porque eles estavam mostrando justamente na prática, falou,
20:04
olha, quando você está começando a estudar arquitetura de
20:06
software, você estuda muito o Ah, isso funcione, isso não
20:09
funcione, isso é, isso é errado. Só que na vida real é um grande
20:13
20000000 de tons de cinza, a arquitetura que não é.
20:16
Se isso vem certo e errado, a arquitetura é um conjunto de
20:18
trade offs, não existe a arquitetura perfeita, a
20:22
arquitetura linda. Mesmo se você pegar um projeto
20:24
específico, vão haver trade offs.
20:27
Você vai ficar limitado pelo tempo que você tem, pela
20:30
estrutura que você tem, pelo dinheiro ou pela equipe do
20:33
cliente que depois ele vai manter isso.
20:35
Eu disse, pô, eu vou criar um isso aqui estado da arte, vou
20:37
criar um micro serviço, sei o que tal, às vezes o cliente tem
20:40
um cara de DevOps. É como é que vai manter uma
20:42
estrutura de micro serviços? EEE de com balanceamento.
20:46
A arquitetura de software é um conjunto de trade Office.
20:49
Só que muitas vezes esses trade Office, o que tá na cabeça de um
20:53
humano é muito. Difícil da IA?
20:56
Conseguir ter mesmo ali de raciocínio e mesmo entendimento.
20:58
Então isso que você falou do dos trade Office, eu IA falar assim,
21:02
Ah, eu corrigi isso, não sei o que dizer não, não é para
21:04
corrigir isso aí, tá aí de propósito.
21:06
Então eu quero isso aí, essa questão da da arquitetura de
21:08
software. Eu acho que a IA, por melhor que
21:11
ela seja, por mais que a gente dá direção e tal, o papel do
21:15
arquiteto eu acho que nunca vai morrer.
21:17
Esse é o papel, eSIM, o arquiteto.
21:19
Ele pode cada vez mais usar a IA para ajudar ele a automatizar a
21:24
parte do trabalho dele. Mas essa interferência do
21:26
arquiteto ter que olhar, ter que entender o arquiteto, ter que
21:30
conhecer DDD, conhecer crina, arquitecture, para ele conseguir
21:35
julgar o que a IA tá mandando para ele.
21:37
Isso eu acho que não vai acabar nunca.
21:39
Mas só só voltando um pouquinho, Luiz, na sua fala aqui que eu
21:42
queria polemizar um pouquinho, né?
21:44
Já que Oo título, né? Do nosso episódio aqui.
21:47
O tema principal do nosso episódio é sobre a morte ou não
21:50
da arquitetura. E eu queria polemizar um
21:52
pouquinho, trazendo outro ponto que eu entendi totalmente, né,
21:56
ainda existem trade offs, ainda existem decisões que quando você
22:00
vai vendo, você vai planejando. Você ainda precisa guiar, né?
22:04
Para onde a IA está indo? Mas se a gente pensa no limite,
22:07
em que sdd é a metodologia que vem cada vez mais predominando,
22:12
ou seja, em que a especificação ela é mais forte que o código,
22:16
né? Ou seja, AO requisito do negócio
22:19
ele é mais forte do que de fato o código que está implementado,
22:22
o código implementado, ele vem se tornando cada vez mais
22:24
barato. Será que não vai chegar um
22:26
limite em que e a gente aqui já falou entre as chaves várias
22:29
vezes, em que eu vou poder jogar.
22:31
Fora o meu código com muita frequência.
22:34
Ou seja, o que que isso significa?
22:36
Que talvez a arquitetura vai ser momentânea, temporária também,
22:42
assim como o código. E o que vai pegar mesmo é o meu
22:45
requisito de negócio. Aí hoje ele vai ser implementado
22:48
com o clinark com, sei lá, né, react no front end e DOT net no
22:54
back. E amanhã eu nem tenho isso mais.
22:57
Eu tenho um monolito pronto, todo mundo em node e.
23:00
E nem tenho essa divisão de camadas mais porque eu joguei
23:03
fora. O que eu fiz aí?
23:05
Claro, né? Assim tem.
23:06
Vamos né? Levar todas as considerações em
23:08
onde, onde estamos agora? Me parece que isso sendo
23:11
totalmente verdade o que eu tô falando, a arquitetura de
23:14
software vai morrer mesmo. Quando a gente chegar em um
23:17
momento que a IAB extraiu a tecnologia, nós vamos sempre ter
23:22
o que o arquiteto vai estar defendendo ou deveria estar
23:24
defendendo, que são princípios testabilidade, escalabilidade.
23:29
As perguntas que a IA não faz se você pedir agora para ela trocar
23:31
de DOT net para Java, você dá um entrar lá agora no Cláudio barra
23:36
gol troca de DOT net para Java. Ela só vai parar quando aquilo
23:39
tiver migrado, porém ela não vai saber o porquê aquilo foi
23:43
migrado. Como aquilo tá me garantindo
23:45
mais eficiência, escalabilidade, como aquilo ali tá me fazendo
23:48
mudar ou porque esse benefício tá sendo feito.
23:51
E eu lembro que há muito tempo atrás ou há 2 anos, já que a
23:55
gente tá vivendo na área da IA. A gente antes vendia times pra
23:58
um cliente que ele defendia AA estrutura interna que é.
24:02
Olha, essa arquitetura aqui que você está trazendo em gol é
24:06
perfeita, mas o meu time conhece o DOT net.
24:08
A gente você vai ter que trazer isso aqui pra DOT net, porque a
24:11
gente que vai ter que dar manutenção.
24:13
Só que agora o trade of que o arquiteto vai fazer é pra
24:15
quantos usuários? Isso aqui tem que escalar.
24:18
Então ele vai começar a se envolver cada vez mais na Infra.
24:20
Quais os guias que eu vou aplicar para garantir que essa
24:23
funcionalidade permanece igual, igual independente da
24:27
tecnologia? Quais princípios eu vou
24:29
continuar mantendo? O que a gente vai ter é o
24:31
arquiteto de software, que é olhando aquilo e vai ter 11
24:35
visão ideal naquele momento que é.
24:37
Ele vai tomar a decisão rápida, com base na experiência.
24:40
Ele vai aquilo e vai dizer, nossa, esse caminho a gente pode
24:43
seguir, porque isso vai garantir.
24:45
Esses 5 checklist aqui, escalabilidade, segurança,
24:49
testabilidade, evolução Futura, minha Infra.
24:53
Ele vai garantir tudo isso? Talvez vai morrer.
24:56
Aquele arquiteto que defende Java defende o datinete porque
24:59
todo mundo aqui só conhece o datinete.
25:01
Isso já é ultrapassado, mas essa pessoa que vai garantir os
25:04
princípios, isso aqui vai atender. 1000000 de pessoas na
25:07
Black Friday essa pessoa ainda vai se tornar muito relevante
25:10
porque ele sabe o caminho das pedras.
25:11
Eu julgo até dizer que o papel do arquiteto de software, ele já
25:16
estava morrendo há uns 2 anos, 3 anos atrás, porque o que a gente
25:20
discutiu aqui sobre códigos padrões dentro do projeto, isso
25:25
já vem sendo abstraído pelos tech leads e acaba que o papel
25:28
do arquiteto. Com tanta tecnologia diferente,
25:31
com tanto serviço de nuvem, com tanta tecnologia, né, minha
25:35
arquitetura distribuída, et cetera, o papel do arquiteto se
25:38
ocupa mais em alinhar as decisões técnicas, não, não a
25:42
nível de projeto, mas a nível a nível macro, né, da solução em
25:46
si, né? E aí que que eu fui entender o
25:48
que que era a diferença, né? Que eu ficava olhando assim, né,
25:50
no LinkedIn, Ah, fulano é arquiteto de software, fulano
25:53
colocou que é arquiteto de soluções, aí tipo assim, fulano
25:57
colocou que é arquiteto corporativo.
25:59
Aí eu conseguiria limitar 2 pontos, né?
26:02
Essa parte de arquiteto de software que, na teoria.
26:05
Desde 2000, e. 14 eu sou arquiteto de software, mas de 14
26:10
a 19 eu foquei muito na parte de de software em si, de 19 para
26:14
frente, que aí eu consegui entender o que que era o
26:17
arquiteto de soluções. Esse vai persistir bastante, né?
26:20
Esse? É o cara que consegue conectar a
26:23
diretoria com com o stakeholders, com com a parte
26:27
técnica, né, da, da, da sua empresa, os desenvolvedores
26:31
etcétera esse esse papel é de Extrema importância, né?
26:34
E vem muito assim com que eu questionava de de big text, por
26:38
exemplo, em big text geralmente você tem o software enginer, né?
26:42
Sênior software enginer, né, o Júnior, o media level, etcétera
26:46
e assim, arquitetura é um tema compartilhado entre todos, não
26:49
fica só na. Debaixo do braço de uma pessoa
26:52
ou ao arquiteto de software? Por isso que eu acho.
26:55
Que há tempos a arquitetura de software vem morrendo e vem
26:58
sendo diluída, entre outros. Cargos galera.
27:03
O mexerica me convenceu. A arquitetura de software
27:06
morreu. Eu concordo com essas coisas, tá
27:07
que vocês estão falando? É, eu só acho que assim aqui Eu
27:10
Acredito que é. Esse é o retrato atual mesmo
27:13
assim. Mas o ponto é que estamos
27:15
caminhando cada vez mais. Para um cenário em que a gente
27:20
revisa cada vez menos código e que o código é cada vez menos
27:23
importante, eu concordo que o custo continua sendo importante,
27:26
então a utilização de custo vai continuar sendo importante, mas
27:29
é, é isso, assim, eu acho que é o retrato atual é esse mesmo,
27:33
né? Concordo muito com vocês, mas
27:35
não sei qual é o retrato futuro. Assim, sendo bem sincera, não
27:37
sei qual é o retrato futuro, mas uma coisa eu eu eu tenho
27:40
convicção, esses guard railes e o jeito que a gente precisa
27:45
fazer para que AIA seja cada vez mais assertiva é.
27:48
A gente ainda precisa trabalhar nela, né?
27:50
EE, nisso ainda vai ter trabalho por um bom tempo, que é da gente
27:54
ficar o tempo inteiro alinhando e realinhando os nossos agentes
27:57
para produzir as coisas que a gente precisa, né?
28:00
E isso ainda vai precisar de pessoas.
28:03
Que trabalham tecnicamente, mas não só isso, mas que também
28:06
tenham visão de produto, como o micherica falou aí do arquiteto
28:08
de solução, né? Que consiga comunicar com com a
28:11
diretoria, com o stakeholder e consiga ter esse trânsito
28:14
técnico e negócio. Então essa pessoa, eu acho que
28:17
ela realmente continua por bastante tempo, né, fazendo seus
28:21
trade offs e tal, mas talvez esses trade offs são
28:24
modificados, como vocês mesmos mesmo falaram, né, que ele não
28:27
tá mais na no design, talvez da minha, do meu software, né?
28:32
Mas sim, nesses outras, nesses outros desafios organizacionais
28:36
de colocar um produto em produção, que ainda vão
28:39
continuar existindo por muito tempo, né?
28:41
E esse desafio de colocar em produção é o desafio mais
28:44
complexo mesmo, né? Não só de colocar, né, porque
28:47
quando a gente coloca em produção que começa de verdade,
28:49
o desafio é colocar, manter. É crescer um produto, né?
28:53
E isso vai continuar. Esses desafios organizacionais
28:57
é, eles vão continuar existindo. Né?
28:59
Então isso ainda vão precisar de pessoas com esses perfis, né?
29:03
Que navegam bem aí nas 2 coisas é eu.
29:05
Costumo dizer com o pessoal mais próximo assim, né, que enquanto
29:09
a gente tiver problema de dinheiro, de recursos, de
29:12
hardware, vão precisar de pessoas pra ir ajustando, né?
29:15
Quando isso não for mais o problema, a gente vai chegar
29:18
naquele estado, né? Que Ah, não gostei, faz de novo,
29:21
não gostei, faz backup, quero dessa forma agora, mas.
29:25
Imagino que por muitos anos você ainda vai ter as limitações, né?
29:29
De financeira, de tempo, de de credibilidade, de confiança, né?
29:33
Você vai subir uma alteração 100%, né?
29:36
Com conha sem se ligar para arquitetura etcetera.
29:39
E se ocorre 11 falha, um vazamento etcetera.
29:43
Enquanto existirem esses riscos, vão ter pessoas para mitigarem
29:48
os mesmos. Pois bem, minha sorte que o papo
29:50
hoje foi muito bom. Queria agradecer a mexerica,
29:53
agradecer o Jeff Fernanda e você que está aí ouvindo a gente, me
29:57
diz que que você acha papel do arquiteto.
29:59
Morreu aí a matou. O papel do arquiteto ou foi
30:02
mexerica? Deixa aí pra gente os
30:04
comentários, até mais pessoal, até a próxima, até a.
30:07
Próxima, tchau, tchau.