o pai sinto um WhatsApp eu coloco sempre
Olá o vídeo eu sou Adolfo Neto professor
da Universidade Tecnológica Federal do
Paraná e eu sou Gustavo Pinto Professor
aqui na Universidade Federal do Pará e
este éo Fronteiras da engenharia de
software um podcast feito para refletir
sobre o presente e futuro da engenharia
de software Fronteiras da engenharia de
software é um podcast divulgação
Científica e discutir mensalmente
diversificados temas da engenharia do
solo os episódios abordam questões
fundamentais Engenheiro software até os
mais recentes avanços na área de
[Música]
E aí
[Música]
E aí
[Música]
eu estou Esse é o décimo segundo
episódio o último dessa primeira
temporada do podcast e a gente encerra e
essa temporada conversando com o Paulo
Borba o Paulo fez doutorado em qual
sorte e eu já Professor titular do
centro de informática da UFPE o Paulo
investiga e desenvolve ferramentas e
técnicas para melhorar os níveis de
produtividade e qualidade no
desenvolvimento de software de maneira a
reduzir os esforços e substações Paulo
foi também um dos fundadores da empresa
Quality no porto digital neste Episódio
conversaremos com Paulo Borba sobre
modularidade de software tudo bem Paulo
você pode se apresentar para as pessoas
que nos escutam tudo bem Adolfo obrigado
pela oportunidade de estar aqui com
vocês
o trabalho que vocês têm feito é eu sou
professor no centro de informática da
Universidade Federal de Pernambuco desde
95 e trabalham com vários tópicos mas
muitos relacionados à modularidade e
também a confiabilidade de código aí a
principalmente a mistura Entre esses
dois aspectos vem explorando ao longo do
tempo em Paulo a gente titularização
esse princípios da programação já foi
artigo do David parnas que tem mais de 7
mil citações que ele tenta descrever
como é que a gente consegue modularizar
um sistema em diversos tipos de módulos
né mas assim o que é que seria de fato
essa atividade nesse princípio de
modularizar um código quebrar o código
em funções em classes é modularização e
o que mais seria a modularização sim é
esse processo basicamente Gustavo de
quebrar um problema maior um sistema
maior hein
e não dessas partes são chamadas os
módulos e de forma que você tem a
interfaces bem-definidas entre essas
partes que foram quebradas mas como
objetivo bem específico que é detalhado
desde esses trabalhos iniciais do par
nós até um pouco antes em trabalhos que
são referenciados até neste trabalho
Pioneiro do panos Tá mas com o objetivo
principal de você quebrar para que você
obtenha a possibilidade de ter o
desenvolvimento independente que pessoas
diferentes possam tá trabalhando em
módulos diferentes ao mesmo tempo e
depois consigam integrar de forma bem
sucedida essas partes que foram
desenvolvidas de maneira independente
Então isso é fundamental e para nos
motiva isso com o objetivo principal de
aumentar a produtividade da equipe de
desenvolvimento de software e o que é
mais comum até na literatura que a gente
tá mais acostumado a lei n
é mais clássicos em artigos mais
clássicos também que a ideia de você ter
a possibilidade de dar manutenção numa
determinada parte num determinado módulo
do sistema sem que isso atinja vários
outros modos né então é esse essa
manutenção independente também das
partes e por fim o entendimento
independente para que você tenha a
possibilidade de entender um determinado
nódulo sem precisar entrar nos detalhes
do outros modos entender a fundo que é
feito pelos outros modos A então é esse
processo de você quebrarem sistema
empartes chamadas módulos que podem ser
classes funções ou outros mecanismos de
modularização a fornecidos pela
linguagem de programação um esse
objetivo de ter desenvolvimento
independente entendimento independente e
manutenção da Independência
a parte e Paulo o que que não seria
modularização Existe alguma crença que
os desenvolvedores de software tem sobre
o que seja a modularização que eles
acham que estão fazendo quando na
verdade não estão ou então Quais são as
mais práticas de modularização de
software não sei se existe exatamente
uma crença mas algo que eu percebo como
sendo uma faia de algumas pessoas na
indústria quando vão modularizar um
determinado sistema que esse próprio
conceito de boa modularidade do software
ele é relativo ele não é um conceito
absoluto Então não é só uma determinada
estruturação a determinada quebra do
sistema em partes ela pode ter um
benefício para uma determinada situação
mais ser uma mais estruturação para uma
outra situação então o conceito de boa
modularidade
é relativo e eu acho que isso não é
percebido por muita gente relativo no
sentido de que uma determinada
modularização ou determinado a quebra do
sistema em partes ela vai favorecer
alguns tipos de mudanças outros tipos de
mudanças não vão ser favorecidos que eu
sou sem imagina um sistema estruturado
em camadas por exemplo você modificar
uma determinada camada é relativamente
simples porque as interfaces entre as
várias camadas estão bem definidas tá
então isso permite porque você é altere
uma determinada camada modifica uma
determinada camada sem afetar as outras
mas se nesse mesmo tipo de sistema
solicitação de mudança for por uma mudar
o comportamento de uma história de um
caso de uso isso é algo que vai
atravessar todas as camadas Então você
vai precisar alterar código em várias
camadas
o conceito de modularidade ele de boa
modularidade é relativo eu acho que
pouca gente percebe Paulo voltando lá
para o artigo do David parra ele começa
abre o artigo dizendo abre a fica né que
modalização é um mecanismo para melhorar
a flexibilidade e compreensão do sistema
e forma a diminuir o seu tempo e três
movimentos né pelo que a gente já
começou a conversar aqui agora eu
entendo bem nossa separação de
responsabilidades né mas assim que que
ele quer dizer com relação a
flexibilidade como é que a gente ganha
flexibilidade modularizando o sistema né
e de que forma eu consigo modular
modalizar um sistema para que eu consiga
ganhar por exemplo essas esses atributos
de flexibilidade e compreensão de código
não só que você habilidade justamente um
tópico que a gente já tocou que é só
pode ser vista em dois aspectos Na
verdade o primeiro aspecto é você
conseguir estruturar o sistema de forma
que se você precisar mudar alguns
e você vai mudar facilmente e o outro
aspecto que está atrelado Inclusive a
ideia de linhas de produtos de software
que é você fazer com que uma determinada
parte do sistema funcione com variações
implementações alternativas de uma outra
parte do sistema tá então a modularidade
ela permite isso na medida em que essas
partes esses módulos eles são separados
com interfaces claramente definidas tá
então você pode mais facilmente trocar
uma determinada a parte dessa por outra
e você tem um sistema que funciona de
uma forma diferente do que você tinha
antes essa estruturação do sistema em
partes quando feita de forma adequada
ela permite essa facilidade de ou mudar
uma parte sem afetar as outras ou de
fazer quando eu
a parte do sistema funcione com versões
alternativas de uma outra parte do
sistema aí Paulo qualquer a relação de
modularidade com os princípios de design
de software por exemplo a gente muito
comum hoje empregar vários princípios
como Solid né que a gente tem como por
exemplo aquele princípio de
responsabilidade única que uma o módulo
Uma clássica e somente uma única muito
motivo a única razão para mudar né tem
também aquele tem sido aberto fechado em
que uma classe ela é aberto para
inscrição porém ela é fechada Para
modificação né então aparentemente esses
princípios eles ajudam na modalidade Mas
tem alguma relação assim claro né Eu
tenho uns offer bem desenhado por um
design bem sofisticado isso garante que
eu tenho só fica bem modularizado também
é esses conceitos estão muito atrelados
né E por uma questão histórica boa parte
desses princípios
a todos do solo e de Eu considero o que
são princípios que tendem a favorecer um
fator específico de qualidade de
software que é a modularidade Mas quando
você vai projetar um sistema Quando você
vai fazer o design de um sistema você
tem que contemplar vários fatores de
qualidade obviamente os fatores de
qualidade relativos a corretude atender
aos requisitos que foram especificados
pelos clientes e stakeholders em geral
do sistema mas também vários outros
requisitos não-funcionais inclusive o
aspecto de modularidade mas por uma
questão histórica boa parte do que a
gente vê em livros e na literatura de
engenharia de software relativos à a
princípios de projeto eles estão
relacionados à modularidade mas não
necessariamente tem que ser assim então
se eu quero projetar um sistema e um
fator um fator de qualidade importante
para esse sistema
e é tempo real per formas Pode ser que
eu preciso e seguir princípios que vão
me levar contra modularidade Então os
princípios eles têm que ser alinhados
com os objetivos que você tem para o
projeto de um determinado sistema mas
como uma razão histórica tudo que a
gente vê de princípios está relacionado
à modularidade de software em grande
parte certo se você for atrás de um
livro de por exemplo padrões de projeto
para sistemas de tempo real para
sistemas concorrentes você vai ver ali
princípios implícitos né embutidos nos
padrões e são diferentes do que a gente
vê em princípios mais divulgados e mais
difundidos como só lhe dê o outros
princípios relacionados à modularidade
de sócio parte então você
é um sistema bem projetado significa que
ele tem uma boa modularidade em geral
sim mas não necessariamente tô queria
desacoplar essas essas duas ideias de
Que bom projeto é um projeto que atende
aos requisitos que foram especificados e
que são prioritários para aquele sistema
Mas pode ser que modularidade por alguma
razão específica não seja eu já
Participei de projetos em que
modularidade e não era o principal fator
não tinha que embarcar o software no
celular muita pouco muito pouco a
memória muito pouco mulher recursos
computacionais e de bateria então
basicamente e modularidade e não era o
principal fator a ser considerado é a
gente tinha que jogar fora isso isso
aqui aquilo era um mau projeto do ponto
de vista de modularidade e sim mas do
ponto de vista dos requisitos do que era
necessário para aquele sistema
o projeto mas essa discussão ela
torna-se um pouco confusa justamente por
que por razões históricas se deu muito
valor à modularidade então na literatura
é esses princípios de modularidade eles
têm um uma visibilidade muito Maior
interessante e agora a gente tem uma
pergunta que está relacionada com
conceitos que eu me lembro que eu vi na
minha graduação né polimorfismo o
information aiding que talvez uma
tradução seja escondimento de informação
esses conceitos se eles podiam ser
exercitados em uma linguagem de
programação como ser mais as linguagens
orientadas a objeto ser mais mais Java
Ruby tornaram-se eu uso mais seguro pois
o programador não precisa mais lidar com
outros e tornar esse uso desses
conceitos mas conveniente Mas quais
foram os avanços mais recentes de que
forma de linguagem de
o avançado de forma a garantir novos
mecanismos de modularização de software
é interessante essa pergunta
principalmente porque alguns desses
conceitos de modularidade e como
information Highway né que você falou
Eles foram propostos de forma
independente da linguagem de programação
então quando a gente lê este primeiro
artigo de pernas um de Paraitinga subiu
o uso do for the compositions é quando a
gente vai lá tem o conceito de
Information Highway mas ele é
independente de um recurso oferecido por
uma linguagem de programação então a um
conceito que não está atrelado a uma
linguagem de programação mas de novo
Muitas pessoas aprenderam Inclusive eu
aprenderam esse conceito de Information
on Hidden através de mecanismos como
private de linguagens de programação mas
essas ideias não estão necessariamente
atrelada
Você pode ter o conceito pode ter o
recurso na linguagem de programação tem
formas de você da melhor suporte a
modularização do sofre sem
necessariamente passar por mecanismos
linguísticos oferecidos pela linguagem
de programação é importante entender
isso dito isso a gente tem tido o avanço
sem novos recursos oferecidos pelas
Vagem programação como mecanismos como
três aspectos e vários desses mecanismos
hoje estão embutidos ou estão implícitos
em Frei mortos em Sistemas mais eles
estão disponíveis em linguagem de
programação tão Progresso foi nesse
sentido há um progresso que recentemente
ele não é tem sido a gente não tem tido
o avanço mais nessas nessas nesses
recursos linguísticos ajusta
a limpeza explorar também os recursos
que não são linguísticos então outras
pessoas começaram a explorar recursos
que não são linguísticos mas que vão dar
suporte a modularização do sistema
lembrando o desenvolvimento independente
a manutenção dependente o entendimento
independente não posso ter essas três
características
a independência sem necessariamente
passar por recursos linguísticos
maravilha a gente vai falar agora um
pouco sobre o tema que eu gosto muito de
que a questão da programação funcional
então eu antes de ir me dedicar um pouco
mais tudo como desenvolvedor mesmo
projetos Paralelos a minha atividade
profissional eu trabalhei com 40 só
trabalhava com a linguagem orientada a
objeto Java aí a pergunta se as técnicas
de modo larização são específicas a aos
paradigmas de programação Será que a
modularização de uma linguagem programa
de programação orientada a objeto é
diferente de uma linguagem de
programação funcional agora a gente tem
visto o ressurgimento da programação
funcional que é um paradigma Bem antigo
levem lado lisp mas eu lembro quando eu
estudei na UFPA em 94 95 a gente tinha o
Rafael do helinski naquela época
trabalhava com
e como é que é uma linguagem de
programação funcional com essa
popularização do paradigma de
programação somar os princípios de
modularização mudaram Ou eles são os
mesmos deve ser eu comecei a programar
em linguagem funcionais na UFPE antes
disso viu Adolfo então desde 88 eu
programei em várias linguagens de
programação funcional E isso também é
boa parte da motivação na minha carreira
de pesquisador veio do entusiasmo com a
elegância EA beleza dessas linguagens
hoje em dia tá tudo muito integrado né
então assim hoje em dia qualquer
Linguagem Nova por exemplo você pega tá
escrito ela já mescla conceitos que
originaram das linguagens funcionais com
conceitos de linguagens orientadas a
objeto Então tá tudo muito integrado
Então os princípios eu diria que eles
são bem genéricos Independente de
linguagem as técnicas eles são
é realmente diferente mas tem muita
similaridade Então você pega no agem
como raça o conceito de Tais classes aí
ele vai ter muita semelhança com os
mecanismos de definição de interface cem
linguagens orientadas a objetos são
técnicas diferentes mas tem uma
interseção relativamente grande tô sem
olhar também por exemplo a ideia de
módulo 100ml em sml na stander da ml a
ideia de módulos com interfaces
bem-definidas que chama-la de phantos né
que antes isso daí já veio de linguagens
anteriores como Clear e o BJ né que são
linguagens com as quais eu me empolguei
e trabalhei também bastante durante o
doutorado até um pouco antes disso daí
são imagens fantásticas mas se você for
olhar para o mecanismo de Fantasy 100ml
ele é muito também parecido com
mecanismo
É sim jado nem tão tem uma interseção
muito grande são variações das mesmas
técnicas eu diria os princípios gerais
as técnicas variam de paradigma para
paradigma mas todas com uma inspiração é
comum muito grande Paulo eu acho que é
hoje né 2021 já é um pouco consenso né
que é importante a gente utilizar desses
princípios de modularização e que eles
são até de fato não é bem comuns né até
porque você já falou do Solid né a gente
já discutiu uns minutos atrás mas eu
acho que ainda tem uma certa dificuldade
em criar sofre este fato bem
modularizados um exemplo tem tiver um
frio work de visão né a gente sabendo
que a gente separa um sofrem em duas
três em camadas a gente tem mais essas
camadas que usam freio morto divisão de
JavaScript que hoje tá na moda não tem
muito como fugir né e
a falar para algum profissional você tá
usando angula hoje mude para viu né
assim com certeza não vai ser alto com
certeza vai vai gerar até um estresse no
time porque esse é o tipo de mudança que
é uma mudança drástica mesmo que esteja
sendo em Componentes né arquiteturais
diferente é então é impossível estava
participando de um de um projeto que uma
empresa local que eles pararam de manter
no sol senhor que era em rails 3 ou 4
alguma coisa assim porque o house
evoluiu eles não o produto não evoluiu
junto com a evolução do raios então eles
chegaram no ponto que já conseguiu mais
fazer progresso no produto porque a
versão adição do sistema do Sul amor tá
um pouco mais avançada Então não precisa
necessariamente mudar de extremor
alimentos em baixo atualizar a versão do
poema que já é um passo né então é na
sua opinião é que se deve essa
dificuldade de criar sistemas de fato
bem
é o ponto de vista de modularidade né
fracamente acoplado o problema realmente
complexo né Sistema de complexos e
exigem soluções é que não são simples
não são triviais Então a gente tem que
ter bastante experiência bastante
conhecimento para lidar com isso mais um
ponto principal Gustavo está relacionado
ao que eu falei antes que modularidade
ela é relativo Então depende do tipo de
mudança só que você dificilmente sabe
qual o tipo de mudança mas comum que vai
acontecer naquele tipo de sistema Então
se quando tivesse projetando esse
sistema aí que tem angula como Frei amor
Jazz já existisse a perspectiva de que
daqui a 5 10 anos você mudaria de Angola
Provavelmente o projeto de sistema teria
sido mais cuidadoso e teria levado em
consideração essa possibilidade Mas
provavelmente quando um sistema de
o envolvido problema mim não com muita
frequência quando um sistema deixa
desenvolvido os desenvolvedores não tem
essa visão de Médio prazo nem falar de
longo prazo de que pode haver essa
mudança muitas vezes é uma experiência
que valoriza demais a tecnologia e isso
faz com que perca se um pouco essa
perspectiva essa visão de mais Médio
prazo do que é que vai acontecer naquele
tipo de sistema e socorre como você
falou em relação ao alfrey amor de fogo
e ao frame work de acesso a banco de
dados e assim por diante Então essa
falta de visão do que é que vai ser
necessário mudar e a preparação para que
essa mudança vem a ser feita de forma
mais tranquila é um problema muito
grande além dessa falta de visão uma
outra coisa que
é é é comum aqui às vezes as pessoas até
tem a visão de que aquele Freios de
banco de dados vai precisar se
atualizado vai precisar ser modificado e
assim por diante mas por razões de
performance eles não garantem no projeto
do sistema esse desacoplamento não tem a
ver com aquele trade-off entre os vários
fatores de qualidade que tem que ser
considerado então falta de visão um
aspecto trade-offs é outro aspecto e
outro aspecto muito comum que eu vejo e
observam em alguns projetos é justamente
essa questão de que às vezes as pessoas
usam o Freio amor
e de forma inadequada por falta de
conhecimento mesmo então no código
associado atrelado ao Frei morto deguy
eles colocam detalhes de implementação
que poderiam estar isolados por exemplo
num servidor ou num componente auxiliar
e não é dependente do fêmur de boi tá
então só um Esses são três aspectos que
eu considero importantes mas deve ter
outras outras explicações mas tudo tem a
ver com essa dificuldade em projetar
sistemas então visão conhecimento e
experiência a tudo isso daí tem que ser
levado em consideração para que
realmente e a gente tenha sistemas que a
Tragam melhor perspectiva para gente de
desenvolvimento independente mudança
independente entendimento independente
mas fala um desses problemas que você
e essa falta de visão de Médio prazo nem
se fala de longo prazo né mas como é que
a gente consegue colocar essa visão né
de que as coisas podem e devem mudar em
pouco tempo em dois três quatro cinco
anos dentro do bastante do projeto
dentro do orçamento do projeto dentro de
uma Sprint para a gente tem que entregar
valor para o cliente toda semana né como
é que a gente consegue justificar isso o
nosso gerente que nosso cliente é papel
do desenvolvedor que eu tenho Olha eu
tenho que me preocupar com isso papel do
arquiteto é de quem tem quem tem esse
chapéu aí de ficar visionando o projeto
com relação a essas decisões que Sem
dúvida nenhuma bons e feitas mais que
não são imediatas é o arquiteto
certamente né ele tem que tem que levar
isso em consideração eu acho que ele
seria o principal responsável mas
realmente é muito difícil você vender
para um gerente ou para o responsável
pelo projeto a ter
em cima de uma determinada a mudança que
podem não vir a se tornar realidade tá
mas nesse caso de freio deguy frame de
persistência eu considero que seria um
erro tem uma falha é muito grande por
parte do gerente não entender que isso
vai acontecer é isso daí eu tenho uma
história que mostra que isso tá
acontecendo o tempo todo tá então acho
que seria um erro bastante grande não
considera a isso agora para outros tipos
de mudança e realmente existe essa
discussão entre hora você vai ter
certeza que isso vai mudar então você
quer mais uma camada de software aqui
você quer uma estruturação mais complexa
para permitir que isso vai mudar ou você
adota a filosofia agiu por exemplo de
que quando chegar essa nesse
o que eu vou adequar meu sistema para
isto se realmente tem que ter um
equilíbrio aí de como tomar essa decisão
de quando tomar essa decisão mas é
importante a ver se a equilíbrio né o
seu necessariamente e você não descartar
todas essas possibilidades de mudança
mas também não necessariamente você
aceitar todas essas possibilidades de
mudança
E aí
e você Tem trabalhado mais recentemente
com problema de conflitos de merge você
pode explicar o que seria este problema
é essencialmente um problema de
integração de código e que está
extremamente relacionado com
modularidade porque lembra que como a
gente viu uma dualidade eu um dos
aspectos importantes para de
modularidade e você possa habilitar o
desenvolvimento independente das partes
grande problema é que se eu conseguisse
com frequência dividir as atividades da
minha equipe de desenvolvimento em
módulos de forma que uma determinada
pessoa só trabalha no módulo outro
determinado a pessoa só trabalho em
outro módulo eu nunca teria esse
problema de integração de código pelo
menos no nível sintático Mas isso não
acontece em muitas situações a estrutura
das tarefas de desenvolvimento de soft a
estrutura das demandas feitas pelas
equipes de negócio elas não estão
alinhadas com a estrutura dos módulos do
sistema Então vai chegar a necessidade
de
e terminada a tarefa naquele projeto e
aquela tarefa para ser realizada requer
mudanças em mais de um moto então não
existe um mapeamento um-para-um entre as
tarefas e os módulos do sistema como não
existe isso fica muito difícil você
garante que tarefas diferentes serão
dadas para pessoas diferentes e elas não
vão afetar os mesmos modos não vão
exigir mudanças nos mesmos modos e é daí
onde surgem os conflitos de merge
conflitos puramente textuais acontecem
quando dois desenvolvedores alteram o
mesmo arquivo a mesma classe ao mesmo
tempo né Em cada um em seus repositórios
Independentes mas quando vai juntar vai
integrar as mudanças desse desse Japão
se tornem Independentes os conflitos
aparecem tá então problema não é
essencialmente de má
E aí mas não relacionado com mecanismos
linguísticos das linguagens de
programação um problema gerencial de
integração Nicole tampa extremamente
relacionado e os conflitos textuais eles
que são os mais simples eles ocorrem
quando dois envolvedores alteram áreas
contíguas do mesmo arquivo de uma mesma
classe que aí o sistema não tem como
decidir como de forma não ambígua
escolher uma solução para gerar o
arquivo final que integra as mudanças
dos dois envolvedores então esse é o
problema mais simples de integração de
código que é o conflito de merge textual
mais o conflito pode ser semelhante
esses conflitos semânticos eles são bem
mais complicados eles ocorrem também
mesmo que a gente tivesse uma situação
de mapeamento um-para-um entre tarefas e
módulos
o que a interface entre os módulos ela
tipicamente especificada de maneira
puramente sintática dizendo Qual o tipo
do nome do serviço Qual o nome do método
que vai ser chamado para os parâmetros
que esse serviço vai receber na tipo de
retorno e assim por diante mas não vai
muito mais além disso então pode haver
esses problemas semânticos Mas eles
ocorrem também nessa situação mais comum
e que eu falei que a situação que
desenvolvedores diferentes estão mexendo
no mesmo arquivo ou em arquivos
dependentes E aí pode haver esse tipo de
problema bem interessante Então fica
claro que confio simerj tem muita
relação com o modularidade Mas a questão
que que vem à nossa mente aqui da equipe
do fronteiras é se os desenvolvedores
fossem mais disciplinados com a
modularidade de seu sistema será que
eles teriam menos problemas de Mary
as práticas de integração contínua não
deveriam diminuir estes problemas tá
internet então se esse é um problema
Adolfo que parte dele Pode até ser
negligência dos desenvolvedores mas com
frequência não é com frequência é um
problema de distribuição de tarefas e
desalinhamento de tarefas em relação à
estrutura modular do sistema é um
problema muito mais de que às vezes numa
determinada num determinado projeto ou
não consigo distribuir as tarefas de
forma aqui desenvolvedores diferentes
não mexam nos mesmos arquivos ou em
arquivos dependente é muito mais um
problema às vezes gerencial e muitas
vezes não é nenhum problema gerenciar um
problema que vem de negócio mesmo a
demanda de negócio que naquela situação
é
um Solitário eu implementar algumas
Fitness algumas funcionalidades e o
gerente não tem como naquela interação
distribuir para desenvolvedores
diferentes tarefas que focam em partes
diferentes do sistema então é inevitável
Em algumas situações isso porque ele não
tem como você pedir para o negócio mudar
as prioridades dele num determinado
contexto mas as vezes é negligência
também então se você tem um determinado
desenvolvedor que sem combinar com
ninguém decide renomear ou mudar toda a
indentação do código parte isso vai
gerar uma série de conflitos que
poderiam ter sido evitados mas muitas
vezes é um problema ou gerencial que a
distribuição de tarefas pelo gerente ou
pela equipe em equipes que são Auto
gerenciáveis ela não foi feita de
maneira adequada Em algumas situações
até inevitável ó eu conheço um pouco
seus trabalhos sobre esses problemas
o fêmur e eu sei que tem diferentes
tipos de problemas de conflitos de Mor
já né tem o meu semi-estruturado tem o
estruturado tem o meu G semântico mas
muito fracamente eu não sei bem a
diferença entre esses diferentes tipos
de nerd né você assim que poderia
primeiro te explicar a diferença entre
esses tipos de segundo eles impactam que
maneira diferente o programador o
desenvolvimento de software ou de
maneira geral e como transparente
programador Sim eles não são
transparentes Gustavo e é importante a
gente entender que o problema de
integração de o problema de mexe é
essencialmente você conciliar mudanças
que foram feitas por pessoas diferentes
de forma a você tem um programa
resultante que um é sintaticamente
inválido e 2
e ele preserva as mudanças semânticas
feitas pelos desenvolvedores Não é esse
o problema de forma geral é esse daí
agora tem várias técnicas para facilitar
para resolver de forma mais afetiva
esses problemas e as técnicas Aí sim tem
a ver com o mej estruturado o semi
estruturado E aí por diante tá então
mexe estruturado e sem estruturado são
técnicas que são baseadas na estrutura
sintática da linguagem de programação
e essa estrutura é utilizada para de
forma mais eficaz conciliar as mudanças
vão invés de entender as mudanças
simplesmente como linhas adicionadas e
removidas por um determinado
desenvolvedor gente passa ver as
mudanças como nós de árvores simpáticas
adicionados ou removidos por um
desenvolvedor a estudar uma melhor
acurácia na realização do México é um
problema ou separar ia em um problema de
preservar assim táxi e preservar a
semântica e aí tem técnicas que sim aí
são as ferramentas estruturadas as
ferramentas sem estruturadas são
técnicas diferentes para tentar resolver
esse problema de forma mais eficaz e o
número de semântico eu acho que esse não
dá não ficou muito claro é o médio e
semântico na verdade Denon
um novo tipo de ferramenta tá que tem
como objetivo detectar essa
interferência semântica entre as
mudanças feitas pelos desenvolvedores
que trabalharam de forma independente e
agora a gente precisa integrar o código
que eles fizeram o médico e textual e o
Maggi estruturado e o semi-estruturado
tem como objetivo principal obter como
resultado um programa que é
sintaticamente inválido o médico e
semântico ele ataca o outro aspecto que
é eu quero não só um programa que seja
sintaticamente Vale do que incorpore as
mudanças dos vários desenvolvedores mas
eu quero também tenho certeza e a
integração dessas mudanças não vai gerar
problemas semânticos no comportamento do
sistema no sentido de que um determinado
desenvolvedor pode ter por exemplo
alterado uma variável que vai ser lida
pelo código foi
o outro desenvolvedor e que tinha como
para mim só um valor diferente para
aquela variar Então isso é o que a gente
chama interferência mudança feita pelo
determinado desenvolvedor vai interferir
vai mudar o comportamento a intenção que
o outro desenvolvedor teve quando estava
realizando uma determinada mudanças no
código tá aí a gente tem as ferramentas
textuais para integração de código para
mês de código e ferramentas sintáticas
next nas estruturadas as sem
estruturadas e as ferramentas semânticas
que tentam e um passo além e detectar
não só essas incompatibilidades que
levam a um programa sintaticamente
inválido mas também há um programa
semanticamente inválido ou que não
respeita que não preserva as as
intenções das mudanças feitas pelos
vários desenvolvedores e Paulo você tem
vários trabalhos sobre esses problemas
o conflito de Mogi né E você tem um
trabalho recente chamado the Impact of
structure um software bim tem Street vs
structure virgem Você pode falar um
pouco sobre esse trabalho é me parece
que vocês fizeram um estudo empírico
aqui é um trabalho bem recente pode dar
uma descrição rápida para nossa somente
puxar ver esse trabalho bem interessante
assim eu fiquei bem satisfeito com o
resultado dele principalmente porque na
literatura de média de integração de
código sempre existiu a premissa de
quanto mais estrutura você coloca numa
ferramenta ele mede quanto mais
estrutura uma ferramenta de merge
explora da linguagem que você está
processando mais acurácia você vai ter
na realização do mej - falsos positivos
na e menos falso-negativos vão ser
gerados pela sua ferramenta de mexe
então a ideia
o e desse o resultado principal deste
trabalho é que ele mostra aqui essa
premissa que historicamente as pessoas
tinham se baseado nela por muito tempo
mais de 30 anos se assumir isso que
quanto mais estrutura você coloca na
ferramenta melhor é a ferramenta de mexe
esse trabalho vai na direção contrária e
mostra que sim a um certo ganho quando
você adiciona estrutura mas estrutura
demais pode atrapalhar então é esse
artigo ele mostra aqui as ferramentas
sem estruturadas que tem menos que
explora - estrutura que as ferramentas
estruturadas tem benefícios em algumas
situações site então isso reverte um
pouco a expectativa da comunidade que as
ferramentas estruturadas elas por
explorarem mais estrutura elas natural
os melhores seriam mais precisas nas
integrações de colo aí a gente faz um
estudo empírico para comparar essas
ferramentas ferramenta estruturada e a
semi estruturadas em estruturada foi
construída no nosso grupo de pesquisa a
estruturada construída no grupo de
pesquisa alemão que é que participou
também da elaboração desse trabalho
então foi isso tudo bem interessante
onde a gente tem não só a discussão dos
algoritmos e das ideias as diferenças
entre as ferramentas mas esse resultado
que vai contra um entendimento comum que
a gente tinha há muito tempo na área que
era que quanto mais estrutura a
ferramenta de mexe explora melhor
resultado
a fábrica de casamento
Oi Paulo você tem vestido recentemente
na criação de ferramentas que dão apoio
a estas atividades de resolução de
conflitos emerge Qual é a sua visão com
relação a criação destas ferramentas A
ideia é fortalecer a relação com a
prática cindo foi essas essa realmente
há uma forte motivação com as
ferramentas a gente tem a possibilidade
de impactar diretamente a prática de
integração de código na indústria mas
também tem uma motivação anterior isso
que é advali as ideias que vão surgindo
na nossa pesquisa que primeiro a gente
realizou uma série de estudos empíricos
para entender o problema mais uma vez o
problema distando entendido de no
sentido de Com que frequência os
conflitos ocorrem
e quais são os tipos de conflito Quais
são os fatores de projeto que podem
aumentar a chance de haver conflito de
mexe uma vez tendo esse entendimento a
gente tem o interesse em resolver o
problema temos um entendimento do
problema mas precisamos agora nessa fase
da pesquisa resolveu o problema e não
tem como a gente avaliar empiricamente a
capacidade o potencial da nossa solução
para resolver o problema sem implementar
uma ferramenta então processo natural de
primeiro realizar estudos empíricos para
entender o problema depois procurou uma
solução e essa solução necessariamente
passa pela criação de uma ferramenta e
em seguida um outro processo de estudo
empírico para avaliar ferramenta já
estão esse mais ou menos o caminho da
pesquisa que a gente vem realizando e eu
gosto de fazer o ciclo todo da pesquisa
desde
E aí Tudo problema passando pela solução
pela proposta da solução e avaliação da
solução qual você tá muitas décadas já
envolvido com a nossa comunidade de
engenharia de software né falou Deca nós
porque você mesmo comentou alguns anos
aí ele tá trabalhando com formação
profissional e modularidade e eu não
preciso nem comentar o status atual de
uma situação aqui mas me parece que
mesmo de por causa mesmo por conta de
tudo que tá acontecendo Outra Vez por
conta e tudo que tá acontecendo parece
que a comunidade ela tem se fortalecido
né Você tem alguma intuição de porque é
essa comunidade cresceu tanto nos
últimos anos até eu acho que ela tem se
fortalecido têm obtido uma visibilidade
internacional bem maior do que a gente
já teve antes eu acho que isso é uma
tendência da própria comunidade foi
sendo fortalecida ao longo dos anos né
gerações de professores
as dores e alunos na E aí cada vez mais
caminhando na direção de obter uma
excelência na pesquisa também com a
relevância e é econômica e social então
aqui isso é uma tendência da comunidade
agora eu acho que ela tem sido
fortalecida não necessariamente e por
conta da situação atual mas talvez
apesar da situação atual talvez se a
situação fosse um pouco mais favorável
para pesquisa a nossa comunidade tivesse
mais forte ainda então a minha visão é
mais nesse sentido de que a comunidade
se fortaleceu apesar dos problemas pelos
pais nós temos passado e apesar pelas
dificuldades que a gente tem tido para
fazer pesquisa no Brasil e eu acredito
isso esse crescimento da comunidade a um
crescimento
e da capacidade de fazer pesquisa de
excelência de se inserir imagem Na
Comunidade Internacional Então hoje a
gente tem vários professores brasileiros
trabalhando no exterior como próprio
Fábio então isso ajuda nesse processo de
inserção e também vários pesquisadores e
professores no Brasil que tentaram se
inserir nessas comunidades nos
congressos de primeira linha
internacional através de cooperação
publicações nesses congressos e assim
por diante e isso abriu espaço para os
próprios alunos terão uma formação de
melhor qualidade Hoje os alunos é como
Gustavo Leonardo aqui estão tendo a
oportunidade de alcançar um nível de
visibilidade de realização de pesquisa
de excelência que antes não era possível
e para gerações anteriores não acho que
isso é uma tendência natural fico muito
feliz com ela e tu acha que a comunidade
está de parabéns por ter possibilitado e
ter realizado esse crescimento que a
gente vem observando nos últimos tempos
E aí
[Música]
E aí
São Paulo para você qual é a próxima
fronteira da engenharia de software não
sei exatamente eu acho que tentar prever
o futuro né normalmente é um ato de você
inventar o futuro ou tentar inventar o
futuro e o que eu gostaria de tentar
inventar seria do ponto de vista de
engenharia de sofre mais relacionada à
modularidade seria perspectiva a
possibilidade da gente ter ferramentas
ambiente desenvolvimento que permitam
várias visões modulares do sistema é
algo que já vem sendo pesquisado já foi
proposto tempos atrás mas não virou
realidade ainda então do ponto de vista
de modularidade e eu gostaria de ter um
ambiente e desenvolvimento em que eu
solicito agora eu quero ver uma divisão
no meu sistema em camadas não agora
quero ver
a visão do meu sistema in features eu
quero ver as dependências desta Fit em
relação a outras e o próprio ambiente me
permite isso porque a visão atual é
muito baseada nos mecanismos
linguísticos das linguagens de
programação não gostaria de ir além
porque eu acho que internos de
mecanismos linguísticos já avançamos
bastante e talvez a gente tenha chegado
perto de um teto aí então agora seria
Perspectiva da gente ir além usando
ferramentas não só ferramentas que
facilitam a integração ao Hipódromo
desenvolvimento independente que são
essas ferramentas de Neve mas outros
tipos de ferramentas que permitam os
outros que cubram os outros dois
aspectos que a gente comentou antes que
a um entendimento independente EA
modificação independente das partes do
sistema Então essas ferramentas que
e possibilitam que a gente tenha visões
diferentes divisões modulares diferentes
do sistema eu acho que é seria um bom
seria um bom avanço um avanço importante
nessa perspectiva de modularidade de
sorte Muito obrigado Paulo Borba por
esta presença aqui no Fronteiras da
engenharia de software eu passo a
palavra para você para você fazer suas
palavras finais
e Eu que agradeço Adolfo Gustavo é uma
oportunidade realmente muito boa vocês
estão de parabéns estou sempre
disponível para eu sempre que vocês
tiverem necessidade eu tiver interesse e
entrevistar e eu admiro o trabalho de
vocês principalmente num contexto onde a
academia é cobrada muito pelas
publicações Então você ter pessoas que
investem em outros mecanismos de avanço
como o podcast é realmente algo louvável
e que eu admiro bastante e agradeço pelo
esforço de vocês nessa direção que eu
acho muito importante muito importante
que agradece ser somos nós Paulo muito
obrigado por toda essa conversa e muito
obrigado por ter essa inspiração não só
para mim mas acho que tá muito para nós
e obrigado e para você tem na somente um
abraço e até o próximo episódio do
Fronteiras da engenharia de software II
o Olá obrigado por escutar o Fronteiras
da engenharia de software nossa equipe é
formada por Adolfo Neto Eu Leonardo
Fernandes Fábio petrillo Gustavo Pinto
Danilo Monteiro e Ingrid Nunes estamos
no Twitter e no Instagram como arroba
fronteiras e essa até o próximo episódio
abraços
[Música]
E aí
[Música]