Unknown

[Música] k [Música] Opa boa tarde a todos eh agradeço a presença aí dos alunos que já estão chegando e já estendo Boa tarde a quem mais for chegando durante o seminário Eh estamos abrindo aqui o nosso sexto seminário do ciclo online da programa de pós--graduação em computação e hoje a gente tem um convidado muito especial é um professor aqui da casa professor Léo Murta ele vai falar sobre a linha de trabalho dele e especificamente sobre a experiência dele com o problema eh do gerenciamento de configuração e na verdade o ponto da do seminário né Léo

é é entrar nessa questão de se o gerenciamento de configuração é um problema resolvido né Eh eu É uma honra ter aqui o professor Léo falando pra gente eu queria já agradecer ele pela presença e com isso já te passo a palavra e te desejo uma boa apresentação Obrigado Pedro queria começar agradecendo Pedro e João pelo convite É sempre um prazer né falar em casa aqui para vocês eh deixa eu começar dando um contexto Zinho dessa apresentação essa apresentação eu dei semana passada no CB softw que é o Congresso Brasileiro de software eh era um

dos kotes do evento né uma das dos palestrantes eh e aí o João e o Pedro me convidaram para replicar aqui a apresentação para vocês né Vai ser um prazer né o os slides estão em inglês mas eu vou fazer apresentação em português eh e aí no final a gente tira dúvidas e e conversa aí no que vocês quiserem sobre esse tema né Eh então lá no lá no cbsoft eu comecei me apresentando né Eh aqui não é tão relevante mepr mas eu vou me apresentar um pouquinho até porque essa essa gravação essa essa palestra

fica gravada né E aí depois outras pessoas que estiverem assistindo quiserem conhecer um pouquinho da minha trajetória tá aí né eu fiz graduação na UFRJ mestrado doutorado pós-doc na UFRJ né em lugares diferentes da UFRJ graduação foi no instituto de matemática graduação em computação na época era informática e mestrado doutorado e pós dooc na COP sistemas né e sou professor aqui da uf desde de 2008 eh e eu fui orientado pela professora Cláudia vernia durante toda essa trajetória Né desde do da da iniciação científica até o pós-doc né então minha formação é é UFRJ E

na verdade a mesma professora durante toda a trajetória que é a Cláudia verre Isso aqui começa a mostrar que eu sou cabeça dura porque no meio do caminho Muita gente me questionava Poxa mas Você não acha que você deveria ir para outra universidade para fazer pedaços da sua formação em lugares diferentes ou você não acha que você deveria já que você fez mestrado com a Cláudia você não deveria fazer doutorado com outro professor e eu entendi que não eu entendi que tava dando certo o caminho Tava legal e Eu segui por esse caminho de ponta

a ponta eh eu também apresentei lá no kyote o Instituto de computação Vocês que são da casa tão acostumados e conhecem o Instituto de computação mas como vai ficar gravado acho que vale uma breve apresentação né Nós somos 67 professores no total eh temos 10 postdoc nesse momento a nossa PS tá com pouco mais de 300 alunos de Mestrado de doutorado somos nível seis da Caps e temos três cursos de graduação eh dois presenciais que somam aí uns 1500 alunos eh os dois são nível cinco no enad e e um curso em parceria com a

com FJ Unirio algumas outras instituições aqui do Rio que é o curso do ceder né a nossa implementação da Universidade Aberta do Brasil e a gente tem outros 1500 mais ou menos alunos nesse curso bom e essa palestra Eu Fiz alguns disclaimers no início primeiro eh eu tinha sido Professor homenageado da pela comissão especial de engenharia de software no ano anterior por isso fui convidado para essa palestra esse ano então eu achei que era interessante eu trazer um pouco num contexto pessoal para paraa palestra para enriquecer as discussões da palestra e fazerem com que elas

ficassem um pouco mais concretas Além disso na palestra eu trago um pouco de de Fundações ali de engenheria de gerência de configuração alguns discussões de base e eu falo também de algumas pesquisas que a gente tem feito nesse assunto né e o outro disclaimer importante eu falo muito de código fonte nessa palestra mas muito do que eu falo Vale também para outros artefatos da engenharia de software então planejamento requisitos design elas todos esses artefatos demandam gerência de configuração Apesar de eu tá dando foco em código fonte nesse momento bom então começando pelo contexto pessoal né

eu comecei a iniciação científica na COP sistemas com a professora Cláudia Verne que é essa aqui recebendo flores né Isso já há algum tempinho né eh eu comecei eu tô aqui de de meio Preto né Eh eu comecei lá em 97 e em 98 a gente iniciou um projeto né liderado pela Cláudia Werner de criar uma ferramenta Case voltada para reutilização de software então uma ferramenta que eu posso modelar o ML mas com uma preocupação a mais de reutilização de software e esse resto do pessoal que tá aqui são alunos da Cláudia da época de

doutorado de mestrado de para eh graduação e essa galera toda eh desenvolvia essa ferramenta Case né Então tinha dezenas de alunos durante um bom período de tempo e eu tava fazendo iniciação científica de certa forma era encarregado em juntar o código dessa galera né Vale notar que nessa época não não não existia github na verdade não existia subversion existia cvs sim mas a gente não usava na verdade pouca gente usava controle de nessa época né então eu tinha um pouco a função de eh ter o código eh do odsy que é a ferramenta Case que

a gente estava fazendo e quando alguém pedia eu passava pra pessoa Depois pegava o que ela fez gerava Pet incorporava né eu tinha eu era em algum grau gerente de configuração e isso me motivou muito no assunto né nada como você vê um problema concreto real no assunto para você se motivar a investir e aprender mais sobre esse assunto E aí eu desenvolvi uma ferramenta que foi publicada na sessão de ferramentas dob de 2000 a gente tá falando papo de 25 anos atrás né então é até engraçado que aqui é na no resumo eu falo

que essa ferramenta foi feita em PHP com MySQL com apach né O que tinha na época né Eh Então essa ferramenta ela ferramenta de controle de versão que foi usada no odyssey esse projeto odyssey com com dezenas de desenvolvedores né com uma base de centenas de milhares de linhas de código eh usou essa ferramenta token por um bom tempo em algum momento a gente migrou pro cvs que era a ferramenta open source mais conhecida na época né mas isso tudo me fez olhar para esse assunto com muito interesse e fez com que meu doutorado fosse

nesse assunto né então meu mestrado Não foi nesse assunto minha minha minha própria a projeto final de graduação Não foi nesse assunto mas o doutorado por esse contexto todo eu acabei me interessando E aí eu tenho duas questões difíceis que eu vivenciei durante a minha carreira né Essa 20 anos atrás eu tava numa conferência chamada sbqs simpósio brasileiro de qualidade software lá em Brasília eu era um aluno no meio do doutorado mais ou menos e entrei num ônibus da conferência que levava do hotel para conferência E vice-versa e um professor sor Senta do meu lado

e na conversa ele já me conhecia há algum tempo né falou Léo e aí que que você tá fazendo Fi Ah tô no doutorado agora e tô trabalhando com gerência de configuração E aí ele me fez essa pergunta ele perguntou Poxa mas gerência de configuração não é um problema resolvido eh essa pergunta é uma pergunta bom uma frase só né mas para um cara que tá ali no Meio do doutorado pensem em vocês que estão no doutorado ou mesmo os que estão no mestrado essa pergunta é meio que uma bomba né ele tá perguntando se

se aquele problema é um problema né se ele não tá resolvido já então não faria sentido o meu doutorado naquele assunto né E essa pergunta me fez me trouxe uma reflexão interessante sobre o quão resolvido tava efetivamente o problema de gerência de configuração E aí eu me dei conta que tá resolvido sim desde a década de 70 né então esse slide aqui tenta mostrar para vocês que na década de 70 né só para Recordar como muita gente aqui não é de engenharia de software em 68 69 Teve teve duas conferências da otan que cunharam o

termo engenharia de software e e também o contexto de crise do software que era um momento onde eh software não tava sendo entregue no prazo não tava aí até hoje não é né Eh entregue no custo tinha vários problemas relevantes em relação à software fazer software tava ficando caro eh como resposta a isso na década de 70 teve uma uma evolução bem interessante da engenharia de software entre outras áreas a gerência de configuração evoluiu bastante então se a gente olhar aqui na década de 70 já tinha surgido o primeiro Sistema de Controle de versões que

é o sccs Então já existia controle de versão baseado em locking Então você bloqueava arquivos para ninguém editar junto com você já existia ferramenta de dif já existia ferramenta de build O make foi criado que é usado até hoje em em no é sistema de ser eh ele foi criado na década de 70 então em algum grau a gente pode imaginar que a gerência de configuração foi resolvida na década de 70 da mesma forma que a gente pode imaginar que os problemas de transporte foram resolvidos quando se criou a bicicleta né então agora eu consigo

ir para um lugar mais longe eu consigo eh levar alguma coisa ali junto comigo né só que essa solução que foi dada na década de 70 ela resolveu em algum grau os problemas da década de 70 porque com o passar do tempo vieram outros problemas e vieram outras soluções né então a gente tem hoje um conjunto de soluções eh né nem t no hoje ainda mas na década de 80 e 90 surgiram um conjunto de soluções que vivem até hoje né Aquele modelo baseado em em Bloqueio em locking evoluiu para um modelo baseado em Pet

merge eh começaram a surgir forges online o sce Forge Talvez possa ser visto como uma espécie de um precursor do que hoje é o github né a gente começa a ter técnicas de integração contínua eh tinha uma ferramenta da da Mozilla que era muito interessante eh para integração contínua o bugzilla um is Tracker que hoje é o equivalente ao Jaira ou Hit Hub issues né já tava ali na década de 80 90 então é como se a bicicleta tivesse evoluído pro carro e eu poderia imaginar que o transporte está resolvido quando se inventou o carro

mas não você começa a perceber novos problemas novas motivações que te leva né eu parei aqui em 2000 três pontinhos né mas que te leva a coisas que a gente tem até hoje né e aqui eu botei um helicóptero Mas será que o que a gente conhece hoje por transporte é o que vai estar existindo no planeta daqui a 50 100 anos provavelmente não então esse conceito de Resolvido é um conceito muito questionável e talvez eh com dependência temporal né ele ele tá resolvido em algum grau num determinado momento e ele pode ser evoluído com

o passar do tempo e aí vem a pergunta por que que a gente precisa até agora de pesquisa em gerência de configuração a minha área gerência de configuração até hoje né 20 anos se passaram aí mais até um um pouquinho e e o ponto chave da gerência de configuração é lidar com artefatos compostos e complexos e o que eu vou tentar convencer vocês é que se o software era composto e complexo na década de 70 Hoje ele é muito mais composto e muito mais complexo Então vamos lá primeiro em relação à composição existe um conceito

na engenharia de software que a gente chama de dependence real eh o problema relacionado a você você fazer gestão de muitas dependências num projeto se a gente voltar para aquele projeto odsy que eu comentei há mais de 25 anos atrás ele foi feito em Java Java é uma linguagem nova a gente tá aquele projeto foi em 1998 Java data de 95 então Java tava engatinhando tinha três aninhos de idade como é que era a forma eh mais usual de fazer gestão de dependências de bibliotecas em Java naquela época era basicamente você ter um diretório Lib

ou libs e você jogar o jars dentro daquele diretório se o seu jar tivesse a numeração de versão melhor ainda né mas isso era gestão de dependência quando saí uma nova versão de uma biblioteca era muito difícil atualizar por conta da da transitividade nas dependências porque uma nova versão de uma biblioteca trazia novas versões de biblioteca que ela depende então você tinha todo um problema será que eu posso trocar essa dependência eu não vou quebrar outra biblioteca então isso era o problema da época né nessa época não existia ainda maven maven eh nasceu um pouco

depois e que em algum grau resolveu o problema né o maven permite a gente declarar as nossas dependências e as versões das dependências e ele consegue eh fazer essa atualização de uma forma muito mais controlada Mas o que eu quero mostrar para vocês e convencer vocês que se as tendências daquela época de 20 25 anos atrás eram principalmente relacionadas a bibliotecas e frameworks que a gente usava hoje em dia as dependências São enormes e são diversas Então a gente tem cada vez mais dependências a apis né então quem faz hoje um sistema que é offline

que que vive sozinho né você faz um sistema que ele precisa falar com a API de outros serviços que tão aí pela pela web né E essas apis vão evoluir eu deveria ter um controle sobre a evolução dessas apis porque quando essas apis evoluírem eu posso quebrar eh o funcionamento do meu sistema serviços que tem eh na web serviços em tempo real plugins e extensões né a gente dependendo do tipo de aplicação que a gente tá fazendo ela pode ser estendida né através de plugins eh filas de mensagens assíncronas mecanismos de armazenamento e assim por

diante então cada vez mais o software ele depende de coisas externas aquela ideia do software que ele existe por si só totalmente impensável nos dias de hoje E aí o outro ponto né eu falei da da do fato do software ser composto mas o outro aspecto é a complexidade do software né o grande problema que a gente vive hoje é um excesso de complexidade fazer software há 20 anos atrás era muito mais fácil né Você tava no mundo muito mais isolado Hoje em dia a gente tem um mento de software muito extremamente mais complexo E

por que será que ess que esse software de hoje em dia é tão mais complexo eu vou tocar em dois aspectos primeiro um aspecto funcional o meu argumento aqui é que tudo tá virando ou já é software então tentem pensar nos modelos de negócio ou nos produtos que vocês conheciam há alguns anos atrás se a gente pensa no taxi Táxi virou software virou Uber o hotel hotel virou software virou airbnb a locadora a televisão virou software a música virou software o telefone virou software o carro virou software ou tá virando né então a gente passou

a ter todos os negócios se transformando em softare eh eu lanço um desafio para vocês e não coloquem no chat a resposta o desafio é Qual negócio ainda não virou o software e por que que eu falei para vocês não colocarem no chat Porque se vocês conseguirem enxergar um negócio que não virou software você não tem que colocar no chat você tem que abrir uma Startup e transformar esse negócio em software e aí você vai ganhar alguns Milhões de Dólares dentro de pouco tempo então Praticamente tudo meu primeiro argumento é que tudo tá em algum

grau virando software Esse é o argumento funcional né a funcionalidade dos negócios tá tá caminhando para software e o meu argumento não funcional é que o software tá em todo lugar né num primeiro momento a gente tinha softwares em computadores de grande porte só nas empresas aí teve uma revolução onde o software passou a tá na casa das pessoas no PC das pessoas depois veio uma outra revolução onde o software passou a est na mão das pessoas no celular mas hoje o software tá em absolutamente qualquer lugar então se a gente pensar software embarcado qualquer

dispositivo qualquer a peça de hardware tem software rodando software tá na nuvem software tá na nos eletrodomésticos o software tá no corpo da gente tá medindo a gente um exemplo muito extremo que me chamou muita atenção há alguns anos atrás meu pai teve que colocar um marca-passo então na Essência tem um software controlando o coração dele quer dizer a a preocupação que a gente tem da engenharia de software de fazer um software com pouco defeito ou nenhum defeito idealmente né e um software que funcione da forma que deveria ser ela fica exacerbada num contexto desse

Porque se o software ficar offline por 2 minutos já era né então a gente precisa de de um software de um nível de qualidade muito superior a Talvez o software que a gente estava discutindo há 20 anos atrás isso tudo que eu tô falando traz muita pressão no desenvolvimento de software eu citei aqui não tô tentando ser completo nessa Apresentação mas eu citei aqui alguns aspectos de pressão sobre desenvolvimento de software primeiro a base de usuários hoje de software é o mundo né enquanto algum tempo atrás um percentual não muito grande da população usava software

hoje todo mundo no planeta usa software né a gente tem software em operação 24 por7 e não precisa pensar no marca passo né a gente pode pensar em Sistemas mais convencionais de informação que precisam rodar 24x a gente tem uma necessidade de alta confiabilidade em software né compliance tá ganhando cada vez mais mais relevância né o software tem que tá respondendo a requisitos legais dependendo da área então isso é muito mais intenso privacidade a gente tem lgpd e tem outras outras regras de privacidade cada vez mais fortes que a gente tem que respeitar isso tudo

aqui leva uma base de código muito grande né o volume de código existente hoje é monstruoso e a equipes enormemente grandes para conseguir dar conta do desenvolvimento e manutenção de disso tudo de software né E como é que a gerência de configuração respondeu a isso né no espaço da solução e aqui eu tô falando cm related porque não é só gerência de configuração é tudo que tem a ver com gerência de configuração né No decorrer dos anos então a gente tem eh tecnologia surgindo né Branch surgiram como uma resposta a essas pressões todas merge P

request um pouco mais recentemente contu integração contínuos Deploy delivery aí caminha para devops que é uma tendência muito forte você aproximar equipe de desenvolvimento de equipes de operação a gente tem compilação condicional que é onde a gerência de configuração começa a tocar em outras áreas da computação e Trunk based development que é algo que algumas empresas estão usando feature toggles que é uma é o equivalente ao compilação condicional mas em tempo de execução Então a gente tem um monte de Tecnologia eh surgindo Para viabilizar ou responder à altura a aquelas pressões que eu falei anteriormente

para vocês para tentar concretizar isso que eu tô falando eu trouxe aqui eh um artigo de 2016 então o artigo Já tem 8 anos que retratava como é que era o desenvolvimento do ponto de vista de gerência de configuração na Google eh então notem que o cenário hoje deve ser muito mais intenso né porque já passaram 8 anos aqui mas primeiro ponto interessante a Google pelo menos naquele momento não usava o Git ela criou uma ferramenta própria chamado Piper uma ferramenta que é voltada pro conceito de monoo o Git ele é ele é feito para

você ter um projeto por repositório né então você o normal no Git é você ter vários Eu tenho 15 eh projetos na empresa eu vou ter 15 repositórios a ideia da Google é ter um único repositório que guarde todos os projetos né então ela a gente chama isso de monorepo ela tem um monorepo de naquela época né 2016 86 tb o repositório de gerência de configuração de controle de versões da Google aqui tem algumas estatísticas interessantes mas eu quis destacar duas primeiro que naquela época eles alteravam 15 milhões de de linhas de código por semana

só para dar uma perspectiva o Linux naquela época tinha 14 milhões de linhas de código então é como se eles tivessem alterando um Linux por semana né e e eles faziam na casa de 40.000 comites por dia né num Horizonte de 18 anos você seja terem noção do volume né de mudança que que tava sendo feito equipe de mais de 25.000 desenvolvedores né então aqui só para fechar né eles estavam usando eles reportam Nesse artigo Trunk based development com feature toggles mas o meu ponto aqui é que aquele aquela solução que a gente discutiu da

década de 70 que resolveu os problemas de gerência de configuração simplesmente não consegue lidar com esse volume de mudança com esse volume de desenvolvedores então isso foi foi necessário eh você Reinventar a área algumas vezes Para viabilizar eh lidar com esse tipo de demanda isso era ação e um pouco de contexto pessoal né eu vou entrar agora em alguns aspectos mais fundamentais de gerência de configuração primeiro eu trouxe uma definição eu não quis trazer a definição mais formal que existe da i3e eu trouxe uma definição que eu acho bem legal que ela fala que gerência

de configuração É uma disciplina para controlar a evolução do sistema de software é uma definição da Susan Dart eu acho interessante porque ela vai direto ao ponto né se software evolui e software evolui nós sabemos que evolui eu preciso controlar essa evolução E para isso é que foi criada a gerência de configuração a gerência de configuração ela atua de ponta a ponta no processo desenvolvimento né ela toca no desenvolvimento no release Deploy e em produção só que o foco principal dela tá aqui tá em desenvolvimento os três principais sistemas de gerências de configuração são o

sistema de controle de demandas que é o issue tracking eh o sistema de controle de versões só para dar nome aos bois né Sistema de Controle de demandas muito conhecido é o Jaira um outro é o github issues ah Sistema de Controle de versão muito conhecido é o Git o subversion Mercurial eh esse sistema de controle de build e de controle de dependências então Aqui varia de ecossistema para ecossistema mas se você tá trabalhando com Java ou maven e é uma opção Você tá trabalhando com com rion rails talvez você use o rake e assim

por diante então existem diversos sistemas O make para ser dependendo do seu ecossistema você vai usar alguma ferramenta diferente e ainda sistemas de integração contínua no ambiente mais de release e Deploy a gente tem auditoria gerência de configuração compilação condicional eh entrega contínua Deploy contínuo plantação contínua né e em produção a gente tem o conseito de fature toggles que permite você construir configurações de forma dinâmica em produção ligar desligar a funcionalidade do s o modelo de dados que é usado pela grande maioria de sistemas de controle de versão quando eu falo grande maioria praticamente todos

os sistemas que são comerciais ou que são open source Então se vocês tiverem pensando no Git se tiver pensando no no subversion tiver pensando no no perforce qualquer um deles vai cair nesse mesmo contexto onde é basicamente o que ele guarda são arquivos que Estão guardados dentro dos diretórios esses arquivos podem ter dois tipos eles podem ser binários ou textuais Se eles forem textuais eles são decompostos em linha eh nota que esse modelo é um modelo genérico É o mesmo modelo que o file System do nosso sistema operacional faz uso né Ele é muito genérico

ele tem suas vantagens por ser genérico Mas ele também tem suas desvantagens né então eles de certa forma ele dá algum grau de gerência de configuração ou de controle de versão para um conjunto grande de aplicações o maior problema é que quando a gente faz software a gente tem uma variedade de artefatos que são gerados durante o desenvolvimento então quando eu tô concebendo software eu tenho documentos que descrevem requisitos eu tenho modelos diagramas uml diagramas arquiteturais Quando eu vou pro desenvolvimento eu tenho código eu tenho descritores eu tenho imagens vídeos eu tenho scripts quando eu

vou paraa produção eu tenho os componentes que estão sendo executados eu tenho em última instância tudo isso aqui vai ter que ser guardado nesse modelo de dados extremamente simples né E a nossa dúvida é será que dá Será que cabe será que esse modelo de dados ele é suficiente para guardar todos esses possíveis artefatos que existem durante o desenvolvimento de software e a resposta é sim em algum grau de alguma forma sim por quê Porque tudo que é texto ele vai guardar como um arquivo texto composto de linhas e o que não é textual ele

vai guardar como arquivo binário então sim ele vai conseguir fazer não Vai ser da forma ideal isso aqui já traz pra gente uma motivação de pesquisa né Será que eu posso criar formas melhores e modelos melhores para versionar artefatos complexos Com certeza sim mas o ponto chave aqui é que quando eu guardo alguma coisa como binário eu perco boa parte do suporte que o controle de versão é capaz de dar em específico eu perco a capacidade de trabalho colaborativo que é um uma um uma um aspecto muito importante do controle de versão E aí esse

assunto de trabalho colaborativo concorrente é o ponto que eu quero mergulhar com vocês nota que eu saí de gerência de config ação que é a disciplina mais Ampla entrei em controle de versão daria para eu estar falando de issue tracking daria para eu estar falando de construção cada uma dessas áreas tem eh condições de você fazer pesquisa de de alto nível mas eu fechei em controle de versão e dentro de controle de versão eu tô fechando num problema muito específico eu poderia estar olhando para outros problemas mas eu tô olhando por um problema muito específico

que é controle de concorrência como é que eu consigo fazer com que várias pessoas trabalhem juntas para fazer um produto de software confiável né então como é que eu viabilizou equipes grandes num limite uma equipe daquela lá de 25.000 pessoas na Google né você é uma equipe monstruosa Mas a gente não precisa ir para uma equipe tão grande assim a gente poderia pensar numa equipe de cinco pessoas num equipe de 10 pessoas de 50 pessoas como é que eu faço com que essas pessoas trabalhem em paralelo então o contexto do problema que eu tô querendo

discutir com vocês é o seguinte eu tenho um conjunto de tarefas tarefa de engenharia de software de desenvolvimento de software essas tarefas são alocadas para pessoas que é a minha equipe e para executar a tarefa essas pessoas editam arquivos editam artefatos né Então esse é o meu contexto chave como é que foi a evolução dessa área com o passar do tempo né se a gente olhar lá no início aquele exemplo lá do od antes de ter o controle de versão a gente não tinha nenhum controle e quando não tem nenhum controle você tem um risco

muito grande sobrescrever arquivos então se eu tô editando um arquivo e um outro colega também Talvez um escreva salve e o outro escreva salve por cima isso gera retrabalho isso gera perda de de versões ou criação de versões quebradas né então isso aqui é um problema uma resposta que foi dada a isso é o que a gente chama de política de controle de concorrência pessimista ou baseada em Lock em bloqueio como é que funciona isso eu vou lá e bloqueio o arquivo que eu vou mexer Então ninguém consegue meer em paralelo comigo na verdade eu

tô inibindo a concorrência eu Meo ali sozinho quando eu termino eu devolvo aquele arquivo E aí eu tiro o bloqueio deixo as pessoas trabalharem qual quais são os problemas nota que isso aqui soluciona esses problemas então isso aqui é a solução que foi dada na década de 70 mas isso trouxe novos problemas Quais são os problemas primeiro eu baixo produtividade porque na hora que eu faço bloqueio Eu evito que as outras pessoas trabalh em paralelo eu posso ter deadlocks eu posso ter situações onde a produtividade cai muito e segundo ponto é que eu posso ter

conflitos de ordens mais altas né eu tenho duas pessoas editando arquivos diferentes eles não vão conflitar diretamente um com o outro porque eles estão mexendo em partes diferentes do software Mas eles podem fazer coisas in í veis quando esses dois liberar esses dois arquivos o software para de compilar el para de funcionar adequadamente né mas em função desses problemas vieram outras soluções então década de 80 começa a surgir soluções que a gente chama de política de controle de concorrência otimista Onde eu deixo as pessoas trabalharem em paralelo eu deixo elas editarem o mesmo arquivo em

paralelo mas eu garanto um controle sobre isso de tal forma que no final eu não sobrescrevendo o arquivo da outra pessoa eu consigo combinar eu consigo fazer um merge do desse trabalho que aconteceu em paralelo só que aqui traz um problema quando esse merge não é bem sucedido são identificados conflitos conflitos são situações onde a ferramenta não conseguiu automaticamente eh resolver aquele merge né E esses conflitos às vezes são muito difíceis de serem tratados depois já surgiram técnicas para tentar lidar com isso feature toggles é uma delas né só que por sua vez traz novos

problemas eu não vou botar muita ênfase nessa palestra em feature toggles mas ela também tem seus próprios problemas e eu vou ficar mais aqui no mundo do merd por isso que eu botei essa estrelinha porque é o que mais se usa hoje em dia na maioria das empresas se usa uma política otimista é o que tá no Git por default né e as pessoas fazem merge só que existem merges e merges os merges não são todos iguais né e eu tentei diferenciar aqui três tipos de merge primeiro o merge de espaço de trabalho é aquele

merde que você clonou você fez um pull você tá mexendo aqui na tua máquina por uma hora por 2 horas terminou deu um comite dá um push e Você precisa resolver um merge porque alguém editou em paralelo esse merge normalmente é fácil é um merg onde de um lado tá tá só você que mexeu né não tem outras pessoas é só você que deou do outro lado mais alguém mexeu a o tempo de divergência é curto normalmente então o mest que você normalmente não vai ter muita dificuldade de fazer o segundo tipo de merd é

o merd do P request camarada criou um ramo Ele mexeu naquele ramo eh talvez tenha colaborado com alguém mas usualmente é um cara só eh quando ele termina ele quer que aquele ramo dele seja integrado ao projeto então ele envia um por request Por que que é mais fácil eh é um pouco mais difícil do que o de espaço de trabalho mas não é tão difícil esse mer de p request porque na real o cara normalmente dá um pull antes de fazer eh o merge né na verdade ele faz um merge no sentido oposto ele

traz do ramo principal pro ramo dele então os conflitos que deveriam existir já foram resolvidos por ele quando ele abre o p request de modo geral se isso tivesse sido bem feito ele não vai ter a pessoa que for fazer a integração não vai ter tanto trabalho o o merge mais difícil é esse último aqui é o é o merge de Ramos Então se cria dois ramos pessoas trabalham em paralelo e nesses dois ramos eu tenho diversas pessoas normalmente trabalhando em paralelo nesses dois ramos e no final eu preciso integrar de volta a um desses

Ramos Então esse merd ele tende a ser um merd complicado às vezes esses esses Ramos ficaram isolados por semanas ou por meses né Eu tenho um volume absurdo de comites de cada um dos lados feitos por um número grande de pessoas então eu posso ter muito conflito eu posso ter muita dificuldade de resolver esses ros Então aqui tem um exemplo visual do que eu tô falando né eu tenho uma versão base onde três pessoas estão editando em paralelo se esses caras aqui quando eles terminam de editar tentarem integrar e eles tiverem mexido na mesma região

do código eu vou ter o que a gente chama de conflito né as pessoas editar a mesma região o sistema devolve essa versão pro cara que tá tentando integrar agora pro último né e ele tem que manualmente consertar esse conflito juntar esse código e gerar uma nova versão Então essa aqui é uma situação onde o Git pega duas pessoas editaram na mesma região ele pega um conflito reporta o conflito você faz a integração eu tenho uma outra situação onde pessoas editaram em regiões diferentes o Git é inteligente o suficiente já que não tem um conflito

direto ele é inteligente para combinar essas edições que foram feitas em regiões diferentes e eu botei uma mãozinha aqui rezando por quê Porque o desenvolvedor tem que ter muita fé para acreditar que essa versão tá correta apesar do Git não ter reportado nenhum conflito físico ele pode e ter gerado uma uma versão que não funciona que não é adequada que não está correta né então o cara que tem muita fé Ele termina de fazer fazer isso aí manda pro repositório só que se a gente for um pouquinho mais cético nesse aspecto a gente vai ter

que verificar se essa versão tá efetivamente correta isso leva a gente a alguns tipos de conflito que eu queria que vocês conhecessem a literatura ela fala que conflitos podem ser diretos e indiretos né E ela fala que você tem conflito físico de Build de teste mas essa nomenclatura aqui que o grupo do Paulo Borba da UFPE vem refinando eu acho que é a que melhor eh posiciona os conflitos né então você tem conflito textual sintático eh de eh um um um conflito eh semântico estático e um conflito semântico dinâmico eh eu vou dar exemplos concretos

de cada um deles eu queria que vocês prestassem atenção para vocês entenderem a diferença quando que um é pego ou não pelo sistema de controle de versão eu vou usar aqui sempre o mesmo contexto e também queria que vocês prestassem atenção porque lá na frente eu vou fazer uma pergunta para vocês mas o contexto aqui é um sistema de e-commerce onde eu tô calculando o preço total que tá num carrinho né o itens que estão no carrinho e se a gente olhar aqui esse código que ele faz é botar um zero no preço dá um

loop nos itens e ele soma eh cada um dos preços dos itens né E aí ele tem o preço total aqui duas pessoas editaram em paralelo o primeiro ele adicionou ao preço o shipping né a entrega então ele a mudança que ele tava tentando fazer no software é calcular a entrega né somar entrega ao preço em paralelo uma outra pessoa fez uma mudança no software onde ele colocava desconto num determinado preço né então basicamente um menos o percentual de desconto que ele vai reduzir ali do do preço nota que as duas mudanças de forma isolada

tão perfeitas uma coloca eh shipping e outra coloca o desconto O problema é que da forma que eles fizeram ambos editaram o return né então eu tô tendo aqui uma colisão de de edições e o sistema de controle de versão não sabe muito bem o que fazer como é que ele lida com essa situação onde duas pessoas estão editando a mesma região como ele não sabe o que fazer ele simplesmente devolve pr pra pessoa que tá tentando fazer esse merge e fala cara resolve aí e me fala como é que que é a solução então

essa esse tipo de conflito que a gente fala que é o conflito na mesma região o sistema de controle de versão ele é capaz de capturar aqui é um outro conflito um pouquinho diferente tem aqui Um if que verifica que se se um determinado item tá para remover o item né Verê que se o item tá na sexta Se tiver ele remove nota que em paralelo uma pessoa removeu o if por alguma razão fala não precisa verificar não manda remover direto só que outra pessoa em paralelo colocou um ELS assumindo que o if tá lá

Porque de fato tá se vocês pensarem na versão base a versão base tem o if eh e a remoção um tirou o if em paralelo outro colocou o ELS são regiões diferentes do código não tô editando a mesma região são regiões próximas mas são diferentes na hora que o Git fizer o merd ele vai conseguir fazer o merd automático ele vai remover o if e ele vai colocar o ELS eu vou gerar uma S inválida né A minha árvore sintática abstrata desse código tá inválido esse código não compila né e minha ide ela vai me

avisar se eu tiver usando uma boa ideia ela vai botar aqui um warning um aviso falando que esse código tá quebrado porque ele tem um ELS sem ter o if nota que o Git não pegou isso pelo Git o merge automático funcionou né por isso que eu falei de termo muita fé né porque aquele código não tá necessariamente correto né então esse aqui é o caso que a gente chama de conflito sintático ele quebra sintaxe a gramática da linguagem não tá sendo respeitada aqui é um exemplo de conflito semântico semântica estática eh em paralelo uma

pessoa fez uma refatoração e trocou aqui o nome de um método o método era AD item e passou a ser AD products e uma outra pessoa escreve um método novo que no meio lá do método ele cham add item então notem eles editaram regiões diferentes esses dois mos podem estar muito longe no código o Git vai fazer o merge automático né o Git ou qualquer outra ferramenta de controle de versão vai fazer o merge automático só que esse merge vai gerar uma uma versão que de novo não compila nesse caso eu tenho uma ST válida

a gramática da linguagem a gente tá sendo respeitada só que semanticamente não faz sentido eu chamar um método AD items ele não existe mais ele chama AD products Então semanticamente tem um um conflito aqui isso é o que a gente chama de conflito eh semântico estático porque eu consigo pegar de forma estática uma boa ideia ela botaria aqui um aviso falando cara olha você tá chamando um cara que não existe então ela me avisa que deu algo meio errado nesse merg né mas o pelo Git tá tudo OK com merg e por fim a gente

tem conflito semântica dinâmica é um conflito onde eh o merd acontece sem conflito físico a gramática tá sendo respeitada então nesse exemplo aqui uma pessoa colocou o chipping aqui no somou o chipping no preço total e uma outra pessoa aplicou o desconto lá embaixo então nota eh não teve conflito físico não estão editando a mesma região eh a gramática tá respeitada não tem nenhum efeito eh semântico do ponto de vista da gramática da linguagem acontecendo né todas as as variáveis que estão sendo usadas estão declaradas tá tudo direitinho Então qual é o problema o problema

ele tá na lógica do sistema a gente só vai descobrir que tem um problema aqui quando eu rodar teste né então por isso né a semântica dinâmica do sistema tá sendo afetada se eu rodar bateria de teste talvez eu perceba que tem um problema nesse caso específico qual é o problema eu tô aplicando o chipping em cima do preço mas na hora que eu aplico o desconto o desconto tá sendo aplicado depois do shipping E se a gente pensar na lógica dos sistemas o desconto É sobre o produto desconto normalmente não é sobre a entrega

né então aplicar o desconto depois de aplicar o shipping eu tô dando desconto em inclusive paraa entrega o que faz com que meus testes quebrem se eu tiver teste para isso né Então nesse caso eu tô gerando um código que parece todo correto mas ele quebra uma regra de negócio porque o desconto tá tá tendo efeito no shipping na na na entrega e não é correto ele deveria afetar só o produto bom então como é que são tratadas essas situações de conflito né conflitos são consequências de intenções incompatíveis Eu tenho dois desenvolvedores que editaram o

código eles tinham duas intenções mas a a junção dessas duas intenções foi feita de uma forma incompatível a outra forma de se ver conflito é que a gente tá perdendo a oportunidade de colaboração né se esses caras T se esses caras têm intenções que tão se mostrando incompatíveis se eles tivessem colaborado talvez Eles teriam feito algo melhor mas o ponto Chave É o seguinte a gente tem três formas de lidar com conflito a gente pode evitar conflitos a gente pode detectar conflitos E alertar as pessoas e a gente pode tentar resolver automaticamente os conflitos né

na literatura já se Tentou um bocado de coisas em cada uma dessas frentes em relação a evitar conflitos né lá no início eu já falei com vocês de locking né quando eu bloqueio um artefato eu tô tentando evitar um conflito físico naquele artefato né e efetivamente consigo porque eu não vou ter duas pessoas editando ao mesmo tempo mas eu vou ter conflitos de alta ordem né eu vou ter conflitos sintáticos semântico que a gente acabou de discutir mesmo se eu tiver usando o locking né Eh um outro caminho é a percepção awareness Qual é a

ideia da percepção é eu deixar com que as pessoas percebam que as outras estão editando aquele código Existem várias ferramentas acadêmicas que tem esse propósito Então você tá mexendo em algo se alguém tá mexendo em alguma coisa relacionada a ferramenta te Alerta né E aí você percebe que algo pode dar problema e você talvez converse com a pessoa então você em algum grau Evita o conflito pela comunicação a terceira forma é a alocação tem alguns trabalhos aqui eu botei referências tanto de percepção que é o palantir quanto de alocação que é do Cassandra ambos da

Anita sarma que ela trabalha bastante com essa com esse caminho aí de de evitar conflitos eh alocação é você tentar alocar tarefas lembra lá do início que eu falei para vocês a gente tem que alocar tarefas com as pessoas e elas editam artefatos Se eu conseguir alocar tarefas que são eh de certa forma que uma não tem interferência na outra que sejam mais isoladas as pessoas vão editar partes do código que são independentes e elas tendem a não ter conflito né então se eu conseguisse fazer isso eu diminuiria os conflitos Nem sempre é possível fazer

isso né Às vezes você tem demandas que estão localizadas na mesma região do código então você não consegue eh distanciar e o outro caminho é feature toggles que eu falei para vocês não vou detalhar demais mas a ideia da feature toggles é você ao invés de isolar as pessoas através de Ramos você cria ifs no código Onde por exemplo se eu tô editando Ah tô fazendo alguma funcionalidade nova no código que não tá pronta ainda eu protejo essa funcionalidade com um if com false ali naquele if de tal forma que aquele código não Rode né

então o código vai paraa produção só que ninguém consegue rar aquele código mas por outro lado o código já tá integrado já tá no mesmo Ramo do dos demais códigos do projeto né então é uma forma de eu eh fazer com que conflitos não durem tanto né Eh em relação à detecção de conflito aqui vem uma discussão interessante que eu queria trazer para vocês eh eu escuto muita gente falando que o Git é um sistema de controle de versão de código eu confesso que eu não sei da onde as pessoas tiraram isso claro que eu

posso botar código no Git mas o Git é um sistema de controle de versão de texto n ele não tem conhecimento de código se eu coloco um código Python código JAVA para ele é um arquivo cheio de linhas de texto Então na Essência ele não versiona código na na Essência ele tá aqui ele versiona texto existem abordagens para você fazer detecção de conflito no nível de abstração do código fonte para isso eu preciso extrair a ST a árvore sintática abstrata do código e eu preciso fazer análise no nível da ST só que isso é caro

demais então a gente acaba numa situação interessante né se eu uso uma abordagem baseada em AST situações que o Git marca como conflito não seriam marcadas como conflito eu consigo perceber que foram editadas coisas na mesma região Mas são coisas Independentes então eu não preciso notificar conflito eu melhoro a precisão da minha detecção de conflito eh em última instância eu detecto melhor os conflitos por outro lado eu prejudico muito a performance se eu trabalho de forma estruturada criando ST para todo o código e fazendo a análise no nível da ST isso tudo fica muito mais

lento e tem um outro agravante uma coisa muito legal do Git é ele ser genérico eu verono qualquer coisa no Git se eu parto para uma abordagem que é mais voltada pro código eu vou ficar preso à gramática daquela linguagem de programação então eu vou ter uma capacidade de lidar muito bem com Java por exemplo mas talvez uma linguagem menos conhecida eu não consiga dar suporte Então tem um tradeoff eh entre trabalhar de forma bem genérica como o Git faz versionando texto e trabalhar versionando efetivamente código né Mas você vai ter um preço ali por

fazer isso para lidar com isso surgiram técnicas de merge sem estado é algo aqui no meio né o mer semiestruturado ele tem estrutura em um certo nível mas ele quebra a estrutura e vai para linha de código em outro em outro nível E aí tem técnicas diferentes para fazer esse tuning do do semiestruturado e tentar em algum grau melhorar a precisão do que o Git faz hoje mas ao mesmo tempo não trazer um problema muito grave de performance Então essas são no geral a forma de lidar com melhoria na de conflito e existem soluções para

resolução automática de conflito né uma delas é a próprio merd estruturado que eu tô falando para vocês por quê Porque no momento que ele percebe que um um conflito reportado pelo Git não é um conflito ele tá resolvendo aquele conflito então a gente pode enxergar que ela também eh funcionaria como uma forma de resolver conflito mas tem soluções hoje em dia que fazem uso de Deep learning para escolher Quais linhas de código que deveriam est na solução e tem eh soluções que fazem uso de a generativa para eh gerar código que soluciona um determinado um

determinado conflito E aí eu vou entrar agora nas pesquisas que que eu venho fazendo né eu tô vou falar só de algumas pesquisas mais relacionadas a esse tema né mas o grupo faz diversas outras pesquisas eh em gerência de configuração no geral eh eh mas para eu começar a falar eu queria eu falei lá no início daquela pergunta difícil sobre e se a gerência de configuração não era um problema resolvido isso há 20 anos atrás e há 10 anos atrás teve uma outra pergunta difícil que foi importante para pro grupo né pra gente evoluir eh

a gente tinha eu tinha um aluno de doutorado na época que hoje é professor da federal Juiz de Fora que é o gleif Né o gleif é o tá aqui o primeiro autor desse paper eh o gleif ele tava tentando atacar no doutorado dele um tema muito interessante a gente percebeu que Em algumas situações daria para melhorar a resolução do merge ao invés de fazer um merge no final eu tenho por exemplo tive 10 comites de um lado tive 10 comites do outro e no final eu faço um merge a gente percebeu que ao invés

de fazer esse merge no final se a gente fizesse merges parciais eh Talvez no final a gente conseguiria uma resolução melhor né então era um problema interessante a gente tinha alguns casos que a gente tinha se deparado ele tava já com uma solução caminhando para uma solução legal eh e aí ele foi pro exame de qualificação a banca gostou do trabalho achou que era interessante que devia seguir em frente mas no final um dos professores da Banca O satoro ele fez uma pergunta assim até meio displicente falou mas como frequente é esse problema né E

a gente não tinha essa informação a gente tinha se deparado com alguns casos Mas a gente não sabia quão frequente era então a gente falou não a gente vai dar uma olhada né Depois do e E aí o gleave deu uma mergulhada para tentar entender quão frequente O problema que ele tava querendo atacar era e ele descobriu que era bem raro então assim não fazia tanto sentido a gente jogar energia de um doutorado para resolver um problema que apesar da resolução dele provavelmente seria interessante aquele problema ele não tava acontecendo tanto né a relevância dele

não era tão tão grande só que ao investigar o quão raro era o problema o começou a perceber coisas interessantes né no na mineração de repositórios de de projetos em relação à merge e o foco do doutorado dele mudou por completo né ele parou de de tentar resolver aquele problema e ele passou no doutorado dele a investigar Quais são as questões relacionadas à merge e esse paper aqui é o paper referência do doutorado dele né foi publicado na i3e transactions que é uma das revistas mais importante de engenharia de software e esse paper foi importante

pro grupo porque ele teve muitos achados que motivaram diversos outros trabalhos que vieram depois então eu vou falar de quatro trabalhos que que a gente andou fazendo nesse tema primeiro trabalho em relação à refatoração eh isso aqui é resultado do paper do gleif Ele percebeu que a maioria dos merges T um Chunk né 40% dos merges tem um Chunk que que é um Chunk é a região que tá conflitando Sigam o meu raciocínio aqui se duas pessoas editaram diferentes partes do software quando eu faço merge eu posso ter conflitos em diferentes regiões então um único

merge pode ter 10 chunks são 10 regiões com aquela marcação inha que o Git põe indicando conflito eh o que ele descobriu é que para grande maioria dos merges 40% deles vai ter um Chun se eu pegar 1 e do dois 60% dos merges tem no máximo dois chunks e a gente olha para essa curva a gente percebe que de fato é difícil ter merge com muito Chunk apesar do que tem tem merge aqui com mais de 18 chunks né mas a maioria tá lá no no Um Chunk outra coisa que ele percebeu é que

esses chunks eles normalmente são pequenos né então ele pegou cada um dos merds olhou o número de linhas na esquerda o número de linhas na direita né na v1 e V2 que são as versões que eu tô fazendo merge e ele percebeu que 68 dos chunks tem no máximo 10 linhas na soma ele percebeu que 94% dos chunks tem no máximo 50 linhas que tão em conflito então de modo geral chanes tem poucas linhas apesar do quê se a gente olhar aqui tem um Chunk lá que tem 14.000 linhas de cada lado né então tem

os muito grandes apesar da maioria ser pequeno e no paper do gleif ele deu uma analisada o que que faz eu sei que a maioria tem dos Mestres tem pouco Chunk a maioria dos chunks tem pouco código o que que faz então a gente ter um merge com muitos chunks e o Chunk tem muito código e ele viu que era refatoração Quando acontecem refatorações no código refatorações são aquelas alterações que não mudam o comportamento externo do software né ele tá basicamente melhorando atributos de qualidade daquele software a manutenibilidade a legibilidade e assim por diante né

então quando tem refaturar situações extremas e aí num paper recente o André que é um aluno atual de doutorado ele começou a investigar a relação entre refaturamento de se fazer o medio como é que ele mede o esforço ele usa o uma métrica chamada cod ch que é basicamente quantas linhas foram adicionadas e removidas durante a execução do merge né O cara tá juntando dois ramos Mas além de pegar linhas existentes ele teve que deletar e adicionar coisa se Sim aquilo entra como o esforço do merge então ele percebeu que quando eu tenho refatoração o

esforço aumenta em 24% então isso aqui já trouxe um alerta pra gente ele mergulhou um pouco mais e ele percebeu que merge que tem muitas refatorações merges de Ramos que tem centenas de refatorações esse esforço aumenta em 14 143 por. ele foi Além e ele percebeu que eh merges que tem muitas refatorações ela eles levam a um esforço alto em 232 por então quer dizer a coisa só vai piorando e a última observação dele é que quando eu tenho refações nos dois ramos muitas refatorações nos dois ramos em paralelo o esforço dispara né então eu

tenho um contexto de esforço alto com a probabilidade muito maior então esses achados dele chamar atenção Para um problema né a refatoração aparentemente é um problema sério para merge e agora ele tá fazendo um trabalho já tem alguns resultados preliminares em breve a gente deve ter um paper para mostrar Quais são as refatorações que são incompatíveis Será que tem duas refatorações que eu posso fazer em paralelo que não tem problema não tem tanto problema mas tem outras duas que se eu fizer em paralelo o esforço vai disparar porque se ele encontra resposta para isso talvez

a gente possa pensar em ferramentas que avisem as pessoas né se eu tô mandei minha ideia fazer uma refatoração ao invés de fazer Ela poderia me abrir uma janela e falando cara olha no no outro ramo já fizeram tal refat e a liter fala que essa que você tá pedindo é incompatível com aquela Você tem certeza que você quer prosseguir então isso aqui é uma oportunidade de pesquisa um outro problema que a gente atacou eh o contexto da tese de doutorado da Catarina Costa que é professora da federal do AC Ela percebeu nesse estudo aqui

que esse estudo aqui ela entrevistou ela fez um Survey com 164 desenvolvedores E ela percebeu que poucos desenvol edores se sentem confortáveis em tomar decisão de merge só 32% quer dizer eu tenho aí na casa de 70% desenvolvedores que não se sentem confortável em tomar decisão de merge e a gente também descobriu nesse paper que 75% dos desenvolvedores normalmente contactam outros desenvolvedores quando eles estão resolvendo merge isso que chamou nossa atenção P aparentemente escolher um bom desenvolvedor para fazer o merge faz diferença né já que é uma tarefa tão difícil a gente minerando o repositório

ainda nesse Paper A gente percebeu que tem merges muito difíceis merges de Ramos com muitos desenvolvedores aqui por exemplo no rails tem um merge que tem esse esse sh1 que tem que tinha 47 desenvolvedores num Ramo e 52 no outro ramo quer dizer em torno de 50 pessoas editando num Ramo e outras 50 editando no outro Ramo e no final das contas um cara vai ter que fazer o merge disso tudo que todo mundo fez em paralelo né então é uma tarefa complicada como é que eu vou saber a intenção dessa galera toda e vou

fazer um merge adequado né nota que eu não tô falando daquele ramo aquele merge bobinho eu tô falando de merges complicados agora paraa Nossa a esperança né a gente percebeu que existem situações com intercessão com proporções Diferentes né mas eu tenho situações onde determinado MD Tinha alguns desenvolvedores que atuaram nos dois r Ramos Então esse cara em algum grau ele conhece o que tá sendo feito num Ramo e que tá sendo feito no outro ramo Talvez ele tenha facilidade de integrar em função desse contexto todo a gente bolou uma ferramenta essa ferramenta identifica o que

a gente chama de ke files são os arquivos que estão sendo alterados o mesmo arquivo tá sendo alterado nos dois ramos a gente percebe quem são as pessoas que alteraram esses arquivos no ramo Esses caras são os especialistas na mudança eles sabem muito bem a mudança que tá aconte a gente olha no histórico do projeto e vê as pessoas que mais alteraram o arquivo na história esses caras não conhecem a mudança mas conhecem muito o artefato ele tá acostumado a mexer naquela parte do sistema e a gente olha também PR dependência entre arquivos e aí

no final a gente chega num ranking dos desenvolvedores que a gente entende que são os mais apropriados para executar aquele mer a gente fez experimentos e a gente percebeu que em 85 5% das vezes o top três desenvolvedores que a gente recomenda um desses três é o cara que efetivamente fez o merge né como é que a gente faz esse experimento a gente pega eh projetos existentes analisa a história do projeto encontra os merges e refaz aquele merge para entender o que que aconteceu né então Aparentemente a ferramenta tem um desempenho legal ela consegue recomendar

um top TR que acerta em 85% mas a gente quis fazer uma análise qualitativa dos 15% que ela errou então a gente fez uma amostra de de pessoas e fez entrevista com essas pessoas e a gente descobriu que na real 66% dos casos a pessoa tava junta né Então teve uma pessoa que falou com a gente Cara na verdade assim a ferramenta de vocês não errou porque a ferramenta de vocês recomendou um cara que tava fazendo per programing comigo eu no final das contas dei o comando de de de comite no repositório Saiu o meu

usuário naquele merge mas o cara tava junto comigo poderia ter sido ele então a ferramenta acertou isso que chamou nossa atenção pro merge colaborativo aparentemente algumas empresas e algumas algumas instituições estão trabalhando com m com mais de uma pessoa né mgos difíceis não é o mer fácil mas aquele mer difícil como esse que eu falei com 50 pessoas em cada lado você formar um time para fazer o merge E aí a gente Estendeu aquele paper anterior para tentar buscar por uma estratégia melhor de recomendação de times de merge aquele paper anterior dá um ranking dos

top três caras que são os melhores para fazer um determinado merge Mas a nossa hipótese é que nem sempre os top três vão formar o melhor time a gente trouxe nesse paper o contexto de eh cobertura de conhecimento então eu tenho três pessoas que às vezes o o o dois da fila tem basicamente o mesmo conhecimento do um do ponto de vista de cobertura de de conhecimento ele não agrega muito porque o um Mexe onde el o dois mexe então a gente percebeu que daria para usar otimização para fazer uma busca tentando encontrar Quais são

as pessoas que têm a melhor cobertura de conhecimento quando quando tão juntas na resolução do merge e com essa técnica que a gente trouxe a gente conseguiu melhorar ainda mais a recomendação buscando por outras três pessoas que conseguem formar um time melhor do que os top três da técnica anterior eh a gente também fez pesquisas relacionadas à recomendação desenvolvedor para request tem duas teses de doutorado que que tocaram eles fizeram outras coisas relacionadas a p request Mas eles tocaram na questão de recomendação desenvolvedor É a tese do Manuel e do daric Célio ambos também da

federal do AC foi um dinter que a uf teve com a federal do Acre e eles chegaram a uma curá na casa de 80% 78% o usando técnicas clássicas de a como Random Forest com seleção de atributos e eles conseguiram eh perceber alguns atributos que são relevantes na nessa questão da alocação da da pessoa que vai fazer o merge no caso deles merge de p request eh em relação a essa terceira linha de pesquisa tem um fator muito interessante aqui que vale a pena destacar eh a o trabalho do gleif ele enxergou seis tipos de

resolução de merge é v1 que é eu Quando eu tô fazendo merge eu tenho a versão um a versão dois a esquerda e direita né e eu tenho a resolução do merge v1 é quando eu escolho a versão um para ser a resolução e jogo fora a do V2 é o contrário eu escolho a dois para ser resolução e jogo fora a um acho que deu um pique aqui Tomara que a gente esteja online ainda eh estamos sim estamos sim pode seguir beleza vamos lá então v1 usa um joga fora do V2 usa dois joga

fora um eh concatenação eu junto os dois eu pego o que tá na esquerda e o que tá na direita e ponho um debaixo do outro quando que isso acontece quando eu tenho um conflito na região de importe por exemplo a gente viu que conflito de importe a solução quase sempre é juntar tudo porque você teve gente que importou de um lado Teve gente que importou do outro quando você junta a contribuição dos dois caras você quer juntar os dois importes e aí concatenação resolve a gente tem combinação combinação é quando a gente pinça algumas

linhas de um lado pinça algumas linhas do outro a gente tem New code que é quando a gente escreve um código novo e a gente tem n onde o cara não usa nem v1 nem V2 e mantém a base eh O que que o trabalho do gleif percebeu que só 13% dos chunks precisa de New Code em outras palavras em 87% das vezes o código já tá lá o código da resolução de um merge já está lá e basta eu saber escolher naele código isso motivou a gente a começar a olhar sobre uma ótica de

busca de otimização de pesquisa operacional que na engenharia de software o pessoal chama de search based software Engineering quando a gente tenta usar pesquisa operacional para resolver problemas de engenharia de software eh isso aqui é a tese de doutorado do Heleno já tá quase no fim termina até o início do ano que vem eh e uma descoberta que ele fez que é muito interessante ele descobriu que as resoluções normalmente preservam ordem parcial que que é ordem parcial imagina que eu tenho do lado da esquerda cinco linhas essas linhas estão numa determinada ordem do lado da

direita eu tenho outras cinco linhas que elas também estão numa determinada ordem algumas delas vão participar da resolução não todas necessariamente agora o que o alo descobriu é que em 98% das vezes a ordem que elas aparecem na resolução é a mesma ordem que elas estavam no v1 e no V2 então a ordem parcial é preservada Por que que isso é importante isso é importante porque a gente consegue eh reduzir drasticamente o espaço de busca no momento que eu tenho 10 linhas de um lado e 10 linhas do outro por exemplo se eu não preservo

ordem parcial todas as combinações possíveis dessas 10 linhas seriam soluções válidas né na verdade todas as permutações dela estariam valendo então eu teria um espaço de busca muito amplo na hora que eu percebo que a ordem parcial é preservada meu espaço de busca fica muito mais reduzido porque nunca vai ter uma uma linha que tá abaixo aparecendo acima né Eu sempre vou ter as ordens eh seguidas e como é que é a ideia do search bazer de software Engenheiro dar otimização para resolver esse problema eu tenho um dado conflito aqui que eu tenho nesse exemplo

umas quatro linhas de cada lado quatro ou cinco linhas de cada lado eh eu vou gerar candidatos para resolver esse conflito né candidatos que pegam linhas de um lado e pegam linhas do outro e eu vou ter uma função de fitness que vai ver o quão bom é um candidato e eu vou navegar nesse espaço até eu chegar na minha otimização possível dentro do tempo que eu tenho e escolher para ser a resolução um desses candidatos só para dar um exemplo eu pedi pro Heleno pegar um exemplo de sucesso né não vão ser todos assim

mas para vocês entenderem o problema eh a função dele gerou um primeiro candidato que é esse aqui que vocês estão vendo na tela na verdade é só essa primeira linha aqui que tá em preto né porque todo o resto é código que teria que ser adicionado pelo desenvolvedor para transformar esse candidato na solução né então isso aqui é uma solução ruim eu tô com uma função de Fitness em 032 isso aqui que foi aleatório esse candidato gerado pegou uma linha lá não pegou outras né e a gente começa a fazer busca depois de fazer uma

busca local com o ils Vocês conseguem ver que aqui já tem um pouquinho mais de preto o preto significa o que ele acertou o verde significa o que que o desenvolvedor teria que adicionar para transformar essa solução na solução correta e o vermelho significa o que que o desenvolvedor Dev teria que remover para transformar essa solução na solução correta então quanto mais colorido pior é a solução né Essa é melhor que a anterior mas ainda tá muito colorida depois que a gente fechou a primeira interação do ils você começa a perceber que tá surgindo um

pouquinho mais de Preto depois da segunda interação do ils a gente já tá com uma solução uma similaridade bem razoável da da resolução correta do merge depois de 25 interações do ils eh que levaram 4 Segundos a gente tem uma solução quase correta eu teria que remover esse poste aqui e teria que adicionar esse try aqui do início mas ele conseguiu me colocar numa situação bem mais próxima da resolução correta desse merge e para fechar a gente tem trabalhos voltados para machine learning eh a motivação desse trabalho ainda veio lá do paper do gleif eu

queria mostrar isso para vocês né o gleif ia fazer uma ferramenta eh no e questionaram se aquilo era frequente Ele percebeu que não era desistiu de fazer uma ferramenta passou a analisar um fenômeno olha como é que o paper dele gerou motivação para vários outros trabalhos né nessa análise ele percebeu que algumas características do conflito levam a um aumento de probabilidade de alguns tipos de resolução né Então dependendo de onde é meu conflito dependendo de características do conflito eu vou ter eh um tipo de resolução aquela que eu falei para vocês é a segunda aqui

da lista se eu tenho conflito no importe normalmente eu resolvo com concatenação normalmente significa que a probabilidade disso acontecer é 198 por maior do que a probabilidade comum da base então quando a gente percebeu isso a gente achou que valia a pena lançar a mão de técnicas de machine learning para tentar classificar o tipo de conflito então eu ten aqueles seis tipos de conflito aqui na verdade a gente decompôs concatenação em concatenação v1 V2 do concatenação V2 v1 né mas eu tenho aqui seis tipos de conflito e eu tenho um classificador que consegue classificar a

a tipo de resolução né ele consegue com um dado conflito classificar qual seria a resolução mais provável para aquele conflito a cura da gente tá na casa de 80% então ele ele consegue classificar bem a esses conflitos e o mais interessante é que notem se ele classifica algo como v1 ele não só classificou a estratégia de resolução ele deu a solução porque a estratégia de resolução v1 é usar v1 eu já tenho a solução V2 já é a solução e os dois de concatenação também já são a solução só quando ele fala combinação ou New

code eu não sei qual é a solução então em suma ele acerta a solução do conflito em 70% dos casos e nesses casos de combinação a gente poderia lançar a mão daquela técnica anterior que eu falei para vocês search base para recomendar uma solução e agora eh para terminar eu peguei aquele conflito lá do início aquele conflito físico que eu tinha mostrado para vocês sei se vocês vão lembrar conflito textual que o Git demarcou onde eu tenho duas pessoas editando aqui um cálculo de total da compra uma pessoa tá botando eh o shipping né a

entrega o custo da entrega e outro tá botando desconto no preço e eu perguntei pro GPT eh se ele conseguia resolver para mim esse conflito uma coisa que eu queria destacar gente eu não tô eu tô fazendo um zero shot aqui para não falar que eu não tô falando nada tem duas palavrinhas importantes aqui tem um please e tem um Step by Step primeiro please eu assisti quando era criança aquele Exterminador do Futuro e eu fiquei muito preocupado quando eu vi o GPT por aí então eu decidi como eu tô logado na ferramenta eu decidi

sempre tratar ele com muita educação porque se um dia ele ele resolver voltar para nos atacar ele vai lembrar que o Léo Murta é um cara muito legal e sempre cuidou muito bem dele e provavelmente eu vou sair vivo dessa então o please é importante fica a dica de prompt aí para vocês e o Step by Step é que eu não quero a solução eu quero que ele me discuta para mim os caminhos que ele usou para chegar Ness solução nó que eu não tô falando para ele que isso aqui é um conflito de merge

não tô falando que é de software né eu falei só que é um conflito eu não tô falando para ele como é que interpreta essa marcação que essa marcação aqui significa que o que tá em cima é um lado o que tá embaixo é outro lado nada disso tá sendo falado para ele e tem um detalhe muito importante que eu queria que vocês prestassem atenção eu eh produzir esse conflito numa ordem que se ele simplesmente juntar esses dois códigos ele leva aquele problema de de conflito semântico dinâmico que eu discuti antes com vocês porque nota

eu não posso primeiro aplicar o chipping no preço porque senão quando eu aplico o desconto depois eu dou desconto em cima do chipping o que tá errado a solução semanticamente correta para esse problema é primeiro aplicar o desconto para depois aplicar o chipping então Eh eu tô vendo o chat aqui de vocês eu queria saber se vocês acham se o GPT vai conseguir ou não resolver esse conflito quem tiver opinião responde aí no chat para mim não vale não vale jogar no GPT para ver tem que ser instinto vamos lá pessoal chegou nada aqui ainda

resolve ou não Bom vamos lá vou caminhar aqui pra gente ver a solução que ele deu primeira parte interessante ele identifica né ele fala que o primeiro passo é identificar o conflito né então o que que ele faz ele percebe que o conflito acontece no return do get totel Price então primeiro passo bem interessante né Ele percebeu que o conflito tá na no Statement de return então ele interpretou o código ele interpretou marcação de conflito ele fala aqui que uma versão a Red retorna alguma coisa que a outra versão retorna outra coisa fez o parcer

para mim conseguiu extrair a informação aqui ele fala que ele Analisa as duas versões ele tá analisando a semântica da versão ele fala que a primeira adiciona o shipping no preço e que a segunda aplica desconto multiplicando por isso aqui aqui e aí ele fala que ele tem que fazer a combinação das coisas e notem ele fala que primeiro calcula o preço aplicando o desconto depois adiciona o chipping e ele fecha me dando o código não só me deu o código como ainda botou um comentário aqui falando que ele aplica primeiro o desconto e depois

faz o chip me retorna O código correto da resolução desse conflito E aí eu perguntei para ele aqui explica o que ele fez né aqui eu perguntei para ele mas por que que você decidiu aplicar o desconto antes do chipping que eu falei por Será que foi coincidência né olha o que que ele me responde ele fala que descontos normalmente eh só valem pros itens ele fala que o shipping normalmente é separado e tem um um custo fixo né E aí ele ainda fala aqui de uma questão de consistência lógica mas quer dizer não foi

ao acaso ele conseguiu resolver o conflito não era um conflito tão difícil mas não era um conflito trivial tinham pegadinhas ali no conflito ele conseguiu resolver o conflito corretamente e ele trouxe uma explicação de Por que ele fez essa resolução bom E aí para falar brevemente de futuro né Eh será que a gente vai continuar tendo gerência de configuração né Eu acredito que sim eu acho que a inteligência artificial por um lado você vê que o GPT pode ser um auxiliar legal para fazer médio né então por por um lado ele ele ajuda a gente

mas por outro lado a gente precisa fazer gerência de configuração de ia gerência de configuração de modelos né então modelos de A então Aparentemente a gente vai ter bastante trabalho para eh dar suporte de gerência de configuração no contexto de a isso é importante inclusive quando a gente fala de explicabilidade a gente fala da relevância da gente conseguir eh explicar o resultado de modelo g a uma outra área que traz um desafio interessante a IOT internet das coisas né No momento que a gente tem dispositivos cada um rodando software em diferentes versões e esses dispositivos

colaborando no contexto de um sistema aí isso traz um desafio ainda maior paraa gente para gerenciar toda a configuração disso e para fechar existe uma linha de sistemas autonômicos que são sistemas que se autorre reparam né que que de forma autônoma ela muda a configuração do próprio sistema então isso traz de novo muito desafio pra gente gerência de configuração se trabalhar com sistemas estáticos é difícil imagina a gente trabalhar com sistemas que se autor reparam e que se auto evoluem né E aí só para fechar essa palestra né eu comecei falando porque que eu resolvi

trabalhar com gerência de configuração eh Visitei uma primeira questão difícil que eu tive que é será que gerência de configuração é um problema resolvido E aí eu passo isso para vocês né se perguntem isso né na vocês que estão fazendo mestrado doutorado se questionem se o problema que vocês estão eh atacando não é um problema resolvido E por que que não é né Depois eu entrei aqui numa explicação mais teórica do que que é gerência de configuração trouxe o segundo problema segunda questão difícil importante aí da minha vida que foi no eq do gleif sobre

quão frequente era um determinado problema que é outra pergunta que vocês deveriam se fazer né Será que esse problema que eu tô resolvendo ele vai ter Impacto ele é relevante ou ele resolve uma coisa muito pontual que não é tão relevante assim eh e se isso acontecer muda a direção tá em tempo eh depois eu falei de quatro linhas de pesquisa que a gente andou fazendo no tema e discutir brevemente aqui eh porque que eu acho que gerência de configuração segue sendo e relevante eh eu queria fazer alguns agradecimentos né o primeiro essa foto aqui

é a foto que eu usei eh para divulgar o kyote lá no evento né e e acho que tudo que a gente faz Só dá certo porque a gente tem pessoas que a gente ama ao nosso redor né então Eh o primeiro agradecimento é a família que tá sempre dando apoio para as coisas funcionarem né darem certo segundo agradecimento aos meus alunos aqui eu botei a fotinha dos alunos meus de doutorado mestrado e graduação né Eu brinco muito que se eu pegar todos os meus papers eu devo ter publicado uns 200 e poucos papers se

eu pegar todos os meus papers e deixar só os que eu sou autor único não vai sobrar nenhum paper tudo que eu fiz foi sempre junto com com colaboradores e com alunos né e na Essência Tudo que eu produzo eh resultado de colaboração e de trabalho muito árduo dos meus alunos que são todos excelentes eh e aqui eu botei fotos dos meus coorientadores são professores que coorientadores eu não ia conseguir botar foto de todos os colaboradores eu publiquei muito artigo muita gente diferente mas essas pessoas representam os colaboradores né e acho que a colaboração mais

intensa que existe é uma colaboração de coorientação e por fim né Queria agradecer as agências de fomento que sem elas ia ser muito difícil tocar pesquisa né e e as nossas pesquisas têm sido eh recorrentemente apoiadas pelo CNPQ pela Caps e pela Fater é isso que eu queria trazer para vocês acho que eu passei eu falei pro Pedro que eu ia gastar uma hora gastei uma hora 20 né Tá ótimo L muito obrigado pelo seminário Olha foi muito bom eu queria começar já eu pessoalmente te agradecendo eu posso dizer por mim que eu gostei muito

realmente é uma aula é muito bom te ouvir falar e a apresentação foi muito boa eh eu queria te passar algumas perguntas que fizeram aqui no chat ao longo da apresentação A primeira é do Magno Lombardo ele tinha feito uma pergunta sobre se a ferramenta está disponível e isso enquanto você tava falando da segunda linha de de pesquisa que você apresentou acho que era o TIP merd né aquela ferramenta para identificar lá o merd colaborativo e ele perguntou se essa ferramenta tava disponível então todas as ferramentas que a gente faz a gente faz open source

Com licença Mc que é uma licença super periva Então você faz o que quiser com elas né e a gente coloca num repositório do grupo que fica lá no github a organização é G GS uf então todos os acho que o Heleno tá online tô sem o chat aqui se o Heleno puder botar o RL do do github aí pro pessoal mas eh todos os os projetos estão lá com só chpm também mas todos os outros também estão eh estão lá abertos disponíveis e pode ser usado e pode ser alterado e assim por diante beleza

a outra pergunta é do próprio Eleno então eu sei que ele tá ele tá online e a pergunta dele é até que ponto e a generativa pode ajudar no merd Você acha que a limitação atual nesse sentido é somente de custo ou seja se for viável alimentar o contexto Ela será perfeita eh Então essa é a pergunta que o Heleno tem que responder no doutorado dele né é a gente tá tentando ver Em que situações el tá no celular não consegue mandar tá beleza mas é isso é GES uf GS TR eh eu não sei

se na minha homepage tem um repositório Mas se não tiver eu vou botar o link então Eh me deem uma hora depois de terminar a palestra a gente a gente pode adicionar a descrição do vídeo e botar nos comentários também que ficam fixados depois é o nome da organização no github é James wof Então se entrar github.com bar jamf Se eu não me engano vai cair lá nos repositórios do grupo vai ter tudo lá eh então assim em relação à pergunta do Heleno Eu acho que o Eleno em algum grau vai responder essa pergunta porque

a gente tá tentando tá comparando com uma uma Fer enta de e generativa e a gente tá tentando ver Em que situações que ela funciona melhor e que situações que ela perde por exemplo se base né mas a eu já refleti um pouquinho sobre isso a gente olha muito para open source né a gente tem disponível projetos open source e a gente tenta rodar análise em cima de de projetos open source projeto open source ele é fonte de dado para ir generativa então tem uma primeira situação po até ser uma ameaça validade a gente tem

que tomar cuidado porque pode ser que um projeto que eu tô usando para validar uma para fazer um experimento ele pode ter sido consumido pela iagem generativa né então eh aquele conhecimento daquele projeto pode est dentro do modelo que seria uma espécie de um overfit né então é uma ameaça que a gente às vezes não não para para pensar né mas mas eu posso ser treinado eu não sei com que foi treinado o xat GPT então sei que foi treinado com um monte de repositório Será que ele usou o código do Linux para ser treinado

se eu tô rodando um experimento onde eu reproduzo merges do Linux Talvez eu esteja dando uma vantagem muito forte para ele então esse é um primeiro aspecto que a gente tem que considerar né Eh e um outro ponto que eu acho que é interessante se a gente tá num num aquele código por exemplo que eu dei de exemplo eu botei nome de variáveis muito sugestivos né O código é um código que você bate o olho e você percebe a semântica dele o que facilita para um para uma GNA trabalhar eh se a gente pegar código

do mundo real Às vezes as pessoas escrevem código que não são tão sugestivas então isso traria um nível de dificuldade maior talvez como é a generativa conseguir compreender contexto e e e dar solução né se eu se eu tiver em especial indo para um para um ambiente de código fechado onde eu tô dentro de uma empresa aquele código talvez Trabalhe com domínio que que tá muito distante do treinamento da de uma de uma IAG generativa né então talvez ele tenha menos capacidade de entender aqueles termos e conseguir dar algum resultado de de de alta qualidade

mas tudo isso que eu tô falando são conjecturas são hipóteses Eu acho que o Heleno vai conseguir trazer um pouquinho paraa gente aí no Nozinho do doutorado dele algum contraste e e eu acho que entender isso é importante eh né A minha percepção é que tem dois erros nesse momento a pessoa que põe todas as fichas na a generativa eh tá com uma dúvida joga no chat DPT pega a resposta e assume que é verdade isso é um risco absurdo e eu acho que existe um outro risco muito grande que é pessoas que estão ignorando

e aativa nesse momento se alguém que tá escutando nunca entrou no chat PT nunca fez nenhuma pergunta pro chpt tá em outro planeta deveria eh repar isso porque a gente tá vivendo na minha forma de ver uma revolução muito importante né Eh não é perfeito tem as ações tem os problemas mas eh a gente tem que ficar atento a a esse potencial e e pode haver um certo trabalho iterativo até né na questão do desenvolvimento de código de podem surgir até linters dedicados a a e generativa na hora de fazer conflito de mer né trajet

É nesse caso específico eh eu não fiz interações eu simplesmente mandei aquela pergunta e o que que eu pensei assim eu como pador não me interessa a resposta seja qual ela for eu vou botar no kote vou botar na pal uhum então e veio uma resposta muito boa na minha forma de interpretar eh mas em outras situações e essa interação é muito rica né você mandar alguma coisa ele te dá algum retorno você interpretar aquele retorno questionar ele melhora aquele retorno eh e uma coisa que algumas pessoas falam e eu tendo a concordar o chpt

funciona muito bem quando a pessoa está usando chpt tem muito conhecimento eu sou um excelente programador eu conheço muito aquela linguagem ele vai me trazer alguma coisa que eu vou ter capacidade de ler de entender e é claro é muito mais rápido ler do que escrever então eu tá legal tá legal era isso que eu queria eu incorporo agora no momento que quem tá interagindo com chpt tem pouco conhecimento sobre o domínio que ele tá fazendo chpt pode entregar algo muito ruim e o cara vai achar que é bom e isso traz consequências né Léo

vou te passar uma última pergunta aqui feita pela Daniele deixa Professor o o que o senhor acredita que virá no futuro em termos de evolução do gerenciamento de configuração para conflitos de Marge então eu eu tenho dificuldade de prever futuro né Eu normalmente erro bastante nas minhas previsões de futuro mas eh eu acho que a generativa tá tá contribuindo né hoje em dia tem tinha uma estatística que as pessoas estavam falando que 50% do código gerado hoje em dia tá sendo do código escrito hoje em dia tá sendo escrito por ia né então eu acho

que ia generativa vai ter tem um papel aí interessante mas talvez não seja a única solução tem pessoas trabalhando com diferentes e e isso é mais legal de pesquisa né Se todos os pesquisadores tentar em um único caminho é muito ruim né a gente como como ciência a gente tem que buscar por esses vários caminhos né e alguns caminhos vão ter mais sucesso mas eh um ponto importante se eu tô tentando um caminho e esse caminho não tem tem tanto sucesso eu quero entender pelo menos Em que situações que ele tem mais sucesso eu tô

buscando por um caminho e ele ganha do chat GPT num determinado licho isso por si só já é muito interessante Por que que o GPT não consegue lidar com aquele nicho minha solução tá conseguindo né E talvez essa abordagem de ter um classificador porque se eu consigo num dado do merge saber que aquele merge é do nicho eu uso a ferramenta a se ela não é daquele nicho eu uso a b então eu poderia ir para uma configuração onde eu não tenho uma situação eu não tenho uma única ferramenta de merge Eu tenho um p

de ferramentas de merge e eu consigo escolher até automaticamente Qual é a melhor ferramenta que que tende a a resolver aquele problema né então tem dificuldade de prever o futuro mas eu acho que a generativa vai ter um papel nesse futuro eu não sei o quão grande e um outro ponto também que eu acho que é interessante a gente tá falando deamento né E de vez em quando eu vejo algumas pessoas falando cara há do anos atrás H um ano e pouco atrás eu usei o ch GPT alucinou então não uso nunca mais aí eu

falo pro cara cara a versão que você usou H um ano e meio atrás ela é tão diferente da versão né aqui na esseesse o modelo que eu usei foi o 4 nesse nesse exemplo talvez se eu tivesse usado um modelo muito antigo ele teria feito besteira mas o atual ele evoluiu muito então isso é uma coisa que a gente precisa tá Atento que a pessoa teve uma experiência frustrante com itiva há um ano atrás ou há um ano e meio atrás um ano 1 ano e meio foi um espaço de evolução muito considerável então

a pessoa deveria reexperimentar nesse momento e ver se aquela aquela funcionalidade segue não não entregando o resultado esperado porque talvez já esteja entregando resultado esperado então você vê a gente tava falando de versionamento né eu preciso versionar aí esses modelos e tentar entender a evolução deles até para poder criticar né ao invés de criticar de forma geral criticar aquele modelo que não entregou porque talvez daqui a 5 anos alguns problemas que não estavam sendo resolvidos passem a a ser resolvidos né Uhum com certeza eh bom acho que ficamos por aqui eh Leo tem vários elogios

aqui eu vou botar aqui o Daniele do Heleno e tem mais outros aqui ao longo não vou ficar clicando todos aqui acho que estão todos registrados lá no chat Muito obrigado a todos pessoal eu quero reforçar o agradecimento ao professor le Murta pelo seminário apresentado aqui acho que foi muito legal muito enriquecedor para todo mundo aqui e é agradecer novamente aí pela participação muito bom contar com Pedro Eu que agradeço assim eh tô disponível meu e-mail tá aí né Se alguém quiser aprofundar alguma discussão fica à vontade de mandar e-mail eh eu sempre tô com

as portas abertas é claro que o busco alunos com um determinado perfil vocês devem ter visto que eu trabalho com coisas mais próximas de código então o cara tem que gostar de código não é um engenharia de software mais abstrata uma engenharia de software mais concreta mas se alguém tiver interesse achar o tema interessante eh eu sei que aqui o público nesse primeiro momento são os alunos do IC que já estão aqui os alunos de doutorado que já estão aqui já tem orientadores né É claro que se às vezes depara no no seu na sua

tese uma coisa de versionamento se eu puder ajudar tô disponível mas às vezes esse vídeo disponível se algum aluno algum algum aluno que tá querendo entrar no doutorado né achar interessante esse tema pode entrar em contato comigo para conversar ou algum aluno de Mestrado que gosta do tema pode entrar em contato comigo a gente conversa se o perfil eh alinhar sempre tem espaço para para fazer pesquisa no tema beleza Muito obrigado Léo Obrigado a todos aí pela participação estamos fechando por hoje Tchau tchau he