3 4 5 6 7
[Música]
Olá ouvintes 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 de
divulgação científica que discute
mensalmente diversificados temas da
engenharia de software os episódios
abordam questões fundamentais da
engenharia de software até os mais
recentes avanços na
[Música]
área para esse nosso quinto episódio nós
conversamos com Alessandro Garcia que é
professor na PUC no Rio de Janeiro onde
também lidera o Opus Research Group
nos últimos anos Alessandro tem
trabalhado bastante com degradação de
design e
[Música]
refatoração então se você escutou e
gostou do último episódio de Marcelo
Maia sobre Codes Mells deve também
gostar deste sobre refatoração e como
evitar Cold Mells vem com a
[Música]
[Aplausos]
gente olá ouvintes para este quarto
episódio contamos com a presença de
Alessandro Garcia que é professor na PUC
Rio tudo bem Alessandro você pode se
apresentar para as pessoas que nos
escutam
tudo bem Adolfo gostaria de agradecer aí
o convite né para participar desse
episódio foi com muita alegria que eu
recebi eh esse convite para participar
desse episódio de fronteiras da
engenheiri de software gostaria de
parabanizar a equipe toda pela
iniciativa né que eu acho uma iniciativa
muito importante então é um prazer tá
aqui bom sobre me apresentar a minha
vida na computação começou quando eu
tinha 12 anos né a minha imersão em
desenvolvimento de software começou tão
cedo quanto eh eu tinha 12 anos de idade
foi no ano de
1989 quando eu comecei a fazer cursos eh
de programação né sobre desenvolvimento
de programas mas com foco em aprender as
linguagens de programação né e
desenvolver com essas linguagens que na
época era coball baser e também
participei na época eh eh de concursos
competições de regionais de
programação então h foi nesse momento
que a computação começou a despertar
interesse em mim porque até então
minha meu meus objetivos era ser
profissional em educação física né mas
aí aos poucos né com essa aptidão sendo
desenvolvida desde os 12 anos acabei
indo pra área de ciência e computação
então com 16 anos eu ingressei no curso
de computação a principal coisa que eu
diria que aconteceu na minha graduação
que eu gostei muito foi muito importante
para minha formação ser um membro do
grupo PET né financiado pela CAPS o PET
é programa especial de treinamento eu
recebi uma bolsa de iniciação científica
e o que era interessante no PET é que
você além de fazer as atividades de
iniciação científica você também realiza
uma série de atividades são
complementares a formação de um aluno de
graduação né então a gente trabalha
trabalha muito em atividades em pró da
sociedade né eu lembro que na verdade
meu tema de iniciação científica era uma
metodologia propor uma metodologia
baseado na antiga linguagem logo para
auxiliar ensino de programação para
pessoas com portadoras de necessidades
especiais né necessidades especiais eh
sobre ótica auditiva mental portadores
de síndrome de Dal e aí a gente criou um
laboratório onde a gente trazia essas
pessoas para aprenderem programação
usando a nossa metodologia então estar
no pet muito legal minha carreira porque
ajudou a mostrar a importância da gente
estar contribuindo diretamente para a
sociedade isso foi importante porque
quando você se torna um pesquisador
engenheiro de software a principal
audiência né tem outras obviamente tem
os usuários do sistema mas muitas vezes
pelo menos na mesma pesquisa a gente tá
auxiliando ou engenheiro de software que
é um uma parte reduzida né da da do
conjunto de profissionais da nossa
sociedade então o PET teve essa marca né
de eh trazer a consciência da
importância de trabalhar para a
sociedade sempre pensando no outro isso
foi muito legal e aí a decisão sobre
engenheiro de software foi que durante a
minha graduação ocorreu o primeiro um
simpósio para brasileiro de software na
cidade onde eu morava onde eu onde eu
cursava se computação foi em Maringá e
aí participando do ISBS né principal
evento nacional aí de ger de software
acabei eh decidindo eh investir na área
de geria de software aí fui pro mestrado
na Unicamp lá eu trabalhei na interseção
em algum problema que era a interseção
da engenheira de software com outras
três áreas que é linguagem programação
sistemas concorrentes distribuídos e
tolerância falhas eh o tema era eh a
proposição de um mecanismo de tratamento
de exceções para sistemas concorrentes
sistemas distribuídos né eh porque as
linguagens na época elas davam apoio
para tratamento de sessões ainda hoje eh
o apoio é mais voltado a a a à parte não
concorrente do sistema né onde não há
concorrência então lá o objetivo era
isso construir um mecanismo que desse
apoio a a tratamento de sessões que
ocorrem paralelamente na nas
tradução de um programa que muitas vezes
a ocorrência dessas exceções em conjunto
em paralelo significa que há um problema
um erro mais grave no sistema então a
gente trabalhou com isso e para
implementar esse mecanismo a gente usou
uma arquitetura reflexiva a gente usou
reflexão computacional para estender a
linguagem né a linguagem Java no caso
com eh adotando possibilitando o uso do
nosso mecanismo de tratamento exensão aí
no doutorado eu fui quando realmente
tive um foco muito grande de engenharia
de software
e ali eh o o a grande a subárea que eu
escolhi foi programação aspectos porque
uma das razões porque tem uma
proximidade à programação reflexiva os
objetivos t relação os objetivos de
programação reflexiva programação
aspectos porque são diferentes formas de
você separar interesses transversais e o
interessante programação orientado
aspectos é que as construções da
linguagem você você tinha um apoio à
separação desses interesses transversais
que no caso da minha dissertação de
mestrado interesse transversal o foca
sessão é apoiado por construções da
linguagem não é uma linguagem de
programação linguagem aspectos você tem
lá construção aspecto pode cants etc mas
tirando isso é o domínio aí eu trabalhei
no domínio de aplicação específico
porque na época o que as pessoas vinham
estudando com relação aos benefícios de
programação orientada aspectos era para
modularizar funcionalidades transversais
mais gerais que sempre ocorrem nos
programas então é loging auditoria ou
tratamento de erros tratamento de
excessão né e aí a gente tentou aplicar
a programação oriental aspectos ver os
benefícios desvantagens em sistemas
multiagentes sistemas que são dotados de
alguma inteligência né são sistemas
distribuídos contratados de alguma
inteligência e viu se o aspectos era
realmente que a programação aspecto
surgiu com propósito geral de resolver o
problema de transversionalidade do
interesse em programas e aí a gente foi
bom tá todo mundo estudando eh eh
interesses transversais que são
relativamente mais fáceis de serem
separados vamos olhar para um conjunto
de interesses transversais que talvez
não sejam tão fáceis de serem
modularizados mas que haveria benefícios
do ponto de vista da evolução manutenção
do sistema multiagente então
comportamentos como eh autonomia
mobilidade e etc e aí foi isso aí depois
do doutorado eh eu fui para trabalhar na
Inglaterra meu primeiro trabalho como
professor assistente foi na Universidade
de Lancaster na Inglaterra e lá tinha eh
o grupo de trabalho era muito bom tinha
o Willan Sbervillew que é né escreveu um
dos livros mais usados né em aulas de
engenharia de software em décadas
anteriores tinha o Pit Sawer que era um
cara bastante famoso em ger de
requisitos e uma vez Rashit que liderava
uma rede de excelência em
desenvolvimento software orientado
aspectos na época e aí eu fui para lá
fiquei 4 anos na Inglaterra e aí eu
voltei pro Brasil em
1999 e como professor na PUC R onde eu
tô até hoje atuando como pesquisador
professor
alessandro nesse meio tempo aí né nesses
últimos 20 anos você acabou que mexeu em
muita coisa né tratamento de erros
aspectos design mais recentemente você
também tem um parece um interesse em
microsserviços se você fosse considerar
uma parte da engenharia de software que
você mais concentra os seus esforços
recentemente qual qual área seria essa
bom antes de mais nada confirmo isso né
que meu interesse tem sido
diversificados aí ao longo desses vários
anos quando eu vim paraa PUC para fazer
o doutorado né eu trabalhava no mestrado
eu tinha um tema bem específico bem
definido e sempre trabalhando nas
minúncias daquele daquele tema tão
específico que era tratamento de sessões
e temas concorrentes e aí eu como
curioso né a primeira coisa que eu
perguntei pro meu orientador de
doutorado foi qual que era o tema
principal os temas principais da área
dele ele disse que estudava engenharia
de soft que ele é um pesquisador
engenharia de soft então qual quaisquer
desafios interessantes que se
apresentavam para ele na engenheira de
software ele comprava aquele problema
estudava aquele problema e acabava
trabalhando naquela área então era muito
difícil para ele pontuar interesses
específicos tanto que é um cara que de
fato professor Carlos Lucena meu
ex-orientador que trabalhou em frames
padrões de projetos eh até hoje em dia
esse tema tão na moda que é engenheiro
de software para eh IA ele foi o cara
que escreveu o primeiro livro não sei se
no mundo mas pelo menos no Brasil com
certeza sobre o tema né tem um livro que
ele me mostrou uma vez uma capa amarela
datilografado sobre essa temática de
giro de software para sistemas
inteligentes e hoje a gente vê que eh
frequentemente temos usado o IA para
tratar problemas de engenharia de
software mas mais recentemente como que
a gente pode usar engenharia de software
para melhorar a manetabilidade outros
aspectos de sistemas que são eh que
adotam algum tipo de técnica de a como
aprendizagem de máquina e aí ele disse
que né que era qualquer coisa qualquer
desafio interessante para mim aquilo não
foi muito compreensível na época porque
eu entendia né que como pesquisador na
época jovem eh eh eu deveria ser capaz
de pontuar ali um outro eh tema de
interesse hoje em dia eu entendo mais a
resposta dele e acho que acontece muito
na nossa carreira é que e
exe leva para direções diferentes embora
eu tenha trabalhado com refatoração
degradação de design microsserviço
detecção de funilidades arquitetura de
software sistemas recomendadores
programação colaborativa revisão de
código etc todos esses temas eu acredito
que eles acabam tendo toda uma relação
entre eles eu acho que todos esses temas
que eu estudei tem relação com um ou
outro tema direto que eu estudei nos
meus 8 anos de pesquisa eu acho que
atueei lá em uma série de tópicos
naqueles 8 anos que seria eh mestrado
doutorado e ali um ano de pósdoc antes
de ir pra Inglaterra e acho que esses
temas todos estão relacionados eu diria
que eu assim os os grandes temas de
interesse meus são entender como
identificar problemas que não sejam eh
problemas de software que variam desde
smells
vulnerabilidades a bugs entender esse
processo como ele ocorre como que a
identificação ocorre e eh estudar como
esses problemas eles acabam prevalecendo
por que eles acabam prevalecendo no
código forte até o ponto em que eles são
removidos eu diria que uma uma grande
área do trabalho de interesse minha essa
questão do apoio à identificação de
problemas seja de design de arquitetura
eh problemas relacionados a algum
requisito não funcional como segurança
eh robustez como caso de tratamento
exessão isso tá ligado com a minha como
eu falei no início da minha carreira eu
trabalhei aí com modularização de
interesses transversais interess
transais traz problemas não só como a
modularização mas também como traz
ameaças à segurança e uma série de
outros outros fatores e aí outra grande
temática é a compreensão e o apoio a
boas práticas de design na forma de
catálogos como apoiar o desenvolvedor em
fazer bom design catálogos padrões de
projetos linguagem linguagem linguagem
padrões de projeto frameworks né insites
a partir de direcionamentos a partir de
estudos experimentais e a terceira e
última grande área é apoio a compreensão
e apoio à atividade de remoção do
problema problemas dos problemas tanto
de aqueles que me ensinou em antes mels
vulnerabilidades etc
até eh bugs então eu tenho trabalhado
mais especificamente com coisas
recentemente como
refatoração e também como sistemas de
reparo de programas mais especificamente
de bugs de tratamento de sessões essa
seria as três direções de pesquisa os
três grandes interesses que eu tenho que
vão desde entender a a identificação do
problema né a a a boa prática práticas
que evitam a introdução do problema e
ajudar o desenvolvedor a remover os
problemas lógico que não em todos os
aspectos de cada uma dessas três
temáticas mas em alguns aspectos né
então é o que eu acho agora entendendo a
resposta do meu orientador de doutorado
o que eu o que eu acho que a gente como
pesquisador muitos dos problemas
específicos eles acabam se representando
com sabor diferente ao longo da nossa
carreira quando eu comecei a trabalhar
com identificação de vulnerabilidades em
código fonte muito do que eu conhecia o
problema tinha uma cara muito parecida
da identificação de smells ou
identificação de locais onde podem estar
eh bugs no programa então eu acho que a
gente tem metaproblemas engenharia de
software que a gente ao longo da
carreira quando não são apresentados
novos desafios que a gente tem um
conhecimento prévio de problemas
parecidos instâncias desse método
problema no passado né então eh eu acho
que a gente tá sempre lidando com
problemas que aparentemente diferentes
eles são muito
relacionados
então ainda a questão da diversidade nos
temas embora tenham focado nessas três
grandes temáticas né e acreditar que
eles são e na verdade metaproas que a
gente tá sempre resolver especializações
desse problema eu acho que a
diversificação é algo natural um
pesquisador por quê por exemplo hoje
trabalhando num grande centro como o Rio
de Janeiro a sociedade toda hora tá
batendo na sua porta para eh resolver
problemas diferentes então eh no Rio
existem muitas indústrias e no
ecossistema da PUC nós temos muito
muitos laboratórios que atendem demandas
né das empresas tal então a gente tem o
LES laboratório engenheiro de software a
gente tem o Techgrafh né o Instituto
Techgraf que trabalha muito com a
Petrobras e e aí acaba que você eh tem
você tem os problemas à sua frente e
esses problemas são apresentados a você
e você tem o desejo de resolvê-los né o
que é um pouquinho diferente é
complementar na verdade quando você vai
lá na literatura você vê que um
pesquisador deixou na área que você
trabalha alguma aresta que precisa ser
removida isso também influencia na na
nas escolha dos nossos temas mas acho
que essa questão principal engenheira de
software que é uma área tão aplicada
essa questão das demandas da sociedade
ao longo da nossa carreira ela vai
influenciando e a gente acaba estudando
tópicos diferentes e na realidade num
grande centro também no Rio acho que São
Paulo isso acontece Recife né grandes
capitais é que muitas vezes os alunos
eles vêm para fazer um mestrado ou mesmo
um doutorado em tempo parcial e com uma
temática específica ele trabalha na
empresa X o dono da empresa liberou ele
para ir fazer mestrado doutorado ele e
ele meio que já chega com tema né então
isso também ocorre isso o aluno é muito
bom né você aceita o aluno aluno muito
bom é importante que você também se
adapte né a à motivação que o aluno tem
né a bagagem que o aluno tem e no fim o
fato de trabalhar em tantos temas é
porque eu gosto de trabalhar com pessoas
eu acho que na carreira de pesquisadora
eu acho que a gente tá sempre aprendendo
e trabalhar com gente legal trabalhar
com gente inteligente eu acho que a
gente tá sempre crescendo né e eu acho
que o processo de pesquisa o resultado é
muito interessante mas a jornada é tão
quanto interessante talvez até mais
interessante e eu acho que um uma um
desses aspectos é a possibilidade de
trabalhar com pessoas com pessoas
inteligentes dedicadas com o mesmo
propósito então isso explico assim assim
a minha grande diversidade mas eu acho
que algo que acontece na vida de
qualquer pesquisador que mora num grande
centro eu trabalho num universidade
inserida no grande centro eu eu
compartilho de boa parte da sua fala né
eh principalmente nessa parte de
trabalhar com outras pessoas que você né
tem uma certa admiração que você aprende
junto a gente acaba que moldado também
pelos próprios interesses dos colegas né
então a gente vai abrangindo nossa área
pelas próprias interações com os
[Música]
colegas você mencionou que parte do seu
interesse é em eh refatoração né remover
algum desses problemas né que acontecem
no código do desenvolvedor né explica
pra gente o que que seria refatorar um
código então refatoração é um processo
que a gente realiza durante
desenvolvimento ou mesmo durante
manutenção e evolução é um processo de
reestruturação do software tendo em
vista a a melhoria do seu design do seu
desenho e a reestruturação consiste de
uma série de transformações no artefato
que você tá refatorando que pode ser o
código fonte mas pode ser próprio o
próprio modelo do design pode ser um
modelo conceitual de um esquema de banco
de dados né então ela consiste uma série
de transformações que após
aplicadas espera-se uma melhora na
qualidade do design né espera-se porque
também é ter o papel do desenvolvedor em
escolher as refaturações apropriadas
para que ele para resolver o problema
estrutural que ele tá tentando resolver
com a refaturação e então a refaturação
diferente de outras mudanças ela não
visa aumentar funcionalidades ao sistema
ou corrigir um bug né ela tem o objetivo
de reestruturar o software tentando
melhorar o design atual do do sistema a
definição do Faller né tem a definição
as definições mais antigas da década de
80 depois no livro do Fmer que foi o
livro popular né que ajudou a aumentar o
interesse na área conscientizar sobre a
importância dessa área na definição dele
ele fazer uma associação eh do termo do
termo refatoração com a melhoria do
design do ponto de vista de mais de
compreensidade ou de
manutenibilidade mas quando a gente fala
de design melhoria no design é design
leva em consideração vários atributos
não funcionais então você a gente pode
ter processos de reestruturação que
visam na melhoria do design mais voltada
à compreensão a manutenibilidade mas
também pode pensar em melhoria do design
do ponto de vista de outros requisitos
não funcionais né como de fato a gente
tem visto mais recentemente o interesse
de eh construir padrões né ou mecânicas
de refaturações mecânicas de refaturação
tendo em vista a melhoria do design
sobre a ótica de performance sobre ótica
de segurança sobre a ótica de consumo de
energia então mas no geral é isso a
refaturação é um processo de
reestruturação de software que tem em
vista melhorar o seu design e quando a
gente tá falando melhoria do design
outra coisa que é bastante importante
nessa definição é que muitas vezes a
gente de forma artificial eh até para
ser mais didático mesmo a gente associa
o design com as grandes decisões de
design por exemplo no contexto do
programa orientado a objetos como você
decompõe em classes como você decompõe
uma classe em métodos eh ou no contexto
mesmo arquitetural como você como você
decompõe sistemas e subsistemas mas
design na verdade tá associado a
qualquer atividade de desenvolvimento
então mesmo no código fonte então quando
você escolhe uma estrutura de dados
entre sei lá uma hashmap ou um vetor
você tá fazendo uma escolha você tá
tomando uma decisão né design é tomar
decisões então você a gente também
realiza design no interior do método na
escolha dos tipos são todas atividades
de design que usualmente a gente não usa
muito frequentemente quando a gente
ensina design o que que é design que é
padrões de design a gente não usa muito
termo para essas atividades de design
código fonte para ter uma melhorar a
classificação né ah eu tô trabalhando
design no nível arquitetural trabalhando
em design então design design mais
detalhado eu tô trabalhando com design
do código geralmente tá melhorando o
código mas fala mas tudo isso é design
todas as decisões que a gente toma
levando em consideração os requisitos ou
outros fatores é design então a
refatoração é isso o processo de
reestruturação do software quaisquer
artefatos né do software não
necessariamente o código fonte que visa
melhorar o design quem trabalha com
sistemas configuráveis linhas de produto
que são sistemas que a gente permitem
gerar diferentes programas né ou fazer
configurações que levem a um programa
adaptado a um programa diferente você
pode fazer refatoração até no no modelo
de de features no modelo você tem um
modelo que representa as configurações
tem um modelo que representa as
funcionalidades né os feit e as
possíveis configurações do daquele
programa você pode fazer a refaturação
no modelo de fatures né tendo em vista
melhorar o design do modelo de fatos
então é importante eh eu acho que eh ter
esse entendimento mais global né a gente
fala muito de refatoração de código mas
refatoração ela pode ocorrer em
diferentes níveis de abstração e a
questão de melhoria do design não
necessariamente precisa estar atrelada
com a questão de facilidade de
compreensão só a facilidade de
manutenção mas também com melhorar o
design tendo em vista outros atributos
não funcionais
então Alessandra você tava explicando né
que acho que parte da ideia da
refatoração é você poder né melhorar um
problema de design seja lá o que esse
problema de design seja né eh mas me
explicam você tem alguma ideia de por
exemplo eu fiz uma consulta rápida no
Google agora sobre refactoring e teve
mais de 11 milhões de registros né no
Google né e você falou que a refactory
foi popularizado parte por causa daquele
livro do Martin Fler né mesmo ele tenha
sido introduzido lá na na década de 80
por uma tese de doutorado lá em Urubana
Champan o que que você tem alguma
sugestão de por que houve todo esse
sucesso de refatoração né o que que
propiciou todo esse avanço que hoje em
dia a gente vai numa mesa de barro todo
mundo sabe o que é refatoração né os
desenvolvedores pregam refatoração quase
que diariamente senão diariamente né
então artigos de refatoração a gente tem
aos milhares né eu tenho uma sugestão do
por do por se popularizou tanto então eu
acho que na verdade sempre foi um terma
popular independente o ponto não é
popular né não se usava a palavra mas
essa questão de
reestruturação ela é meio uma atividade
básica né na no desenvolvimento na
manutenção evolução do sistema mesmo
quando a gente não eh usava o nome
formalmente refaturações iam sistemas
sistemas grandes elefantes brancos com
que com uma certa rotina ou não era
necessário fazer alguma reestruturação
então primeira coisa que eu acho que
contribuiu antes de mais nada até antes
do nível da tese de doutorado que você
citou foi o fato de que é um uma é uma é
uma atividade comum por exemplo assim
como padrões de projeto né o padrões de
projeto surgiu lá com o livro do Gama
tal né o sei o termo as palavras mas a
transferência de conhecimento de boas
práticas né para problemas recorrentes é
uma coisa que o desenvolvedor experiente
ele tá fazendo o tempo todo né
então no caso acho que esse é o primeiro
aspecto né que refaturação é uma
atividade meí intrínseca ao
desenvolvimento manutenção e evolução né
pode ser que alguns sistemas não se faça
reestruturação nenhuma mas para alguns
sistemas para sistemas que você quer que
tem ele tem a equipe a organização
precisa que ele tenha uma certa
longevidade a atividade de
reestruturação vai aparecer aqui ou não
tanto que as atividades eh de acordo com
estudos que nós fizemos mas também
outros pesquisadores fizeram e
refaturação ocorre comumente eh em
mudanças onde o objetivo é adicionar uma
funcionalidade então mesmo para você
quando você tá com objetivo de adicionar
uma nova funcionalidade pode ser
necessário alguma reestruturação para
que o design da classe o design do
método possa acomodar aquela as
modificações daquela nova funcionalidade
então é tem essa questão tem a questão
do livro como você mencionou é um livro
didático é um livro muito fácil de ler é
um livro que vai introduzindo aos poucos
o conceito é um exemplo um exemplo
running example onde você para
apresentar os alunos sobre a questão de
treinamento de de
de ensino é um livro que apoia assim
muito bem as atividades do quem tá
fazendo treinamento professor né do
tutor então ele é um ele é um livro eh
muito bem escrito por pessoa que o
follower é uma pessoa que tinha muita
experiência né fácil de ler fácil de
gerir outra coisa que ajuda em gerir de
software em qualquer área é a presença
de catálogos né ele tem lá uma definição
que tudo bem não é de refatoração que
não é a definição mais abrangente do que
a gente vê hoje sobre refatoração mas
tinha uma definição e ele o que que era
interessante naquele livro é que ele
tinha eh para cada tipo de refaturação
por exemplo movimentar um método extrair
um método ele tinha mecânica como passo
a passo fazer aquilo então como se
tivesse entregando para quem tá
aprendendo mastigadinho como fazer
aquela atividade e a outra coisa
interessante do livro é que ele
apresenta eh eh sugestões eh algumas
sugestões de onde aplicar a refatoração
então aí ele fala assim: "Ah aquela
catálogo lá de melsus de mau cheiros né
que foi o tema eh deuns um dois dois
episódios aí anteriores né eh você tem
lá um catálogo de manchers um catálogo
de smells e ele faz um link né ele diz:
"Olha quando você tem um uma feature
envie uma característica estrangeira um
código que tá mais interessado em dados
de outra classe do que nos dados da
classe que ele pertence aplique primeiro
extraia um método e depois movimente o
método." E para cada uma dessas
transformações ele tem lá as
modificações como extrair o método tá lá
A B C D né e a mesma coisa então eu acho
que é um livro que tem todas essas
características que acho que propiciaram
o entendimento a facilidade de
entendimento e também a facil facilitar
a execução por quem tem pouca
experiência em reestruturar software e
aquelas refatorações que estão lá no
livro de fato são fer refaturações que a
gente não todas elas mas algumas delas
são muito frequentes como o caso de
renomear como o caso de eh extrair
método movimentar método subir um método
pra superclasse descer o método pra
subclasse realmente são atividades muito
rotineiras em estudos que analisam
projetos open source projetos eh de
código aberto e ver que ess realmente
essas refaturações são muito frequentes
do ponto de vista de pesquisa eu eh eu
acho que teve a questão do livro mas
também é porque embora a refaturação
vamos dizer assim parece que é simples
ah um conjunto de modificações que eu
vou fazer para melhorar o design mas a
definição de refaturação mesmo ela é
ampla ela é o processo que inclui essas
modificações então a refatoração inclui
primeiramente eh como que você prepara
os testes tá mudando o código fone então
para você realmente fazer refaturação
com com sucesso é importante que você
prepare os casos de teste mas como
escolher esses casos de teste e aí você
aplica a refatoração executa os casos de
teste mas pode ser que o design
alcançado com a reestruturação não tem
os benefícios que você planejava ter com
aquele resultado e isso pode virar um
ciclo e pode ser que a sua refaturação
se você eh inclua na base do código do
projeto né faça parte da da da master
brand da da brand principal do projeto
de fato ela traga para outros problemas
de design que vão requerer refatoração
né então eh o termo a definição do
folder fala do processo né então acho
que é por isso que a gente tem eh tanta
pesquisa associada porque é algo não
trivial né eh e também não passa só para
as atividades que eu mencionei já começa
por identificar onde refatorar então tem
muitos subproblemas associados com
processo de refatoração que eles
sozinhos já são difíceis eh vamos dizer
assim de serem tratados e as ids né
certamente eh uma outra coisa que
contribuiu pra rupularização foi a
incorporação de apoio automatizado
semiautomatizado de tipos de refaturação
populares como
extracto renomear método eh movimentar
método e isso é é interessante porque
até vou deixar para falar isso mais
tarde mas eh os desenvolvedores
frequentemente citam que usam ideias
para refaturar mas isso que significa
que a ideia pelo menos teve objetivo de
ajudar a popularizar mas não
necessariamente como falar mais tarde
daqui a pouco eh a depender das
perguntas que vocês façam não
necessariamente ele aplica com uso de
ideias mas as ideias certamente
contribuíram também para popularização
todos esses fatores contribuíram aí para
essa grande popularidade né é
interessante gostaria de citar uma
revisão sistemática que foi eh do Danny
Dick e outros pesquisadores eh sobre
refaturação 30 anos de refaturação então
ele ora que tem sido feito em pesquisa e
lá de fato isso que o Gustavo mencionou
você vê artigos cobrindo refatoração em
todas praticamente todas as etapas do
ciclo de desenvolvimento e refatorações
com foco em melhorar de design com
diferentes eh eh objetivos de melhoria
de requisitos não funcionais né mais
recentemente como mencionei antes
desempenho segurança então acho que tem
muita muitos subproblemas interessantes
aí para serem resolvidos e a
popularização do tema é natural né que
são problemas reais e a gente precisa
entender esse processo e ajudar o
desenvolvedor nesse processo de
refatoração certo Alessandro e aí tem
três perguntas que eu imagino que vão
passar pela cabeça do desenvolvedor ou
desenvolvedora que por acaso tenha que
explicar isso para alguém é que você já
falou bastante sobre isso mas então por
exemplo por que que a refatoração é
importante você falou aí sobre a questão
de melhorar o design né quando eu sei
que é o momento de refaturar o meu
código você explicou que por exemplo o
livro do Martin Fer ele te dá várias
indicações né de desse momento aí tem
essa questão sempre que você identifica
um um problema que dá para refatorar
você deve refatorar então nesse sentido
eu acho que tem dois aspectos aí eh tem
um aspecto que é tem a ver muito com
treinamento e mesmo o perfil do
desenvolvedor que é aquele desenvolvedor
que refatora de forma proativa ele
aprende as boas práticas ele encarna as
boas práticas e nas atividades que ele
realiza naturalmente modificação
evolução manutenção do código
constantemente ele está preocupado não
significa que ele não vai deixar dívidas
técnicas não significa que ele não vai
deixar problemas estruturais mas ele por
definição um cara proativo com relação a
refatorar ele viu que a primeira
tentativa não foi eh uma boa escolha da
estruturação dos métodos estruturação
das classes ou seja o que for a questão
de do design aí e ele vai lá e refatora
mas esse não esse cara eu acredito que
tem é para que seja possível a gente
aumentar o número de pessoas com esse
perfil realmente a educação o
treinamento tem um papel importante mas
um cenário mais frequente eu vejo isso
acontecendo tanto em projetos de código
aberto como projetos fechados você vai
fazer refatoração quando aquilo tem um
benefício claro no momento que você tá
fazendo uma alteração no momento que
você tá realizando um comite ou a curto
médio longo prazo né mas é importante
que você saiba qual é o benefício porque
se você não souber qual é o benefício
pode acontecer coisas do tipo da
refaturação introduzir outros problemas
dá um caso bem clássico que a gente vê
ocorrendo até em projetos open source
bastante populares né e que os
pesquisadores estudam bastante é
frequente a tarefa do o programador eh
extrair superclasse então quer dizer ele
tá criando uma nova abstração então ele
eh a ideia dele é aumentar a
flexibilidade do design né para que você
crie não tenha só aquela classe concreta
aquela abstração concreta você ter uma
abstração você tem uma classe mais
abstrata e ela vai poder ser reusada e
estendida ao longo do tempo é como se o
desenvolvedor já antecipando e querendo
guiar para que futuras subclasses sejam
criados com aquele formato com aquele
template da superclasse né com aquele
comportamento aquela estrutura que vai
ser dada da superclasse só que a gente
observa que muitas extrações de
superclasse ocorrem duas coisas o
desenvolvedor acaba não usando a
superclasse você não vê acesso à
superclasse é uma melhoria que ele faz
para pensando no médio prazo longo prazo
a gente não sabe não sabe se é porque
realmente o sistema ia precisar evoluir
daquela forma ou se foi algo que ele ah
eu acho que isso aqui é uma deveria ter
uma superclasse aí estrai né e acaba não
criando também subclasses então na
verdade você acabou sem um objetivo
claro sem um propósito bem claro que
aquilo ia ser útil você pode estar
complicando o design então a primeira
coisa que é importante saber na hora que
escolher quando refatorar é que tem um
objetivo tangível para aquela atividade
de refatoração aí eu vou citar algumas
as clássicas né eh por que que você quer
facilitar a manutenção ou seja sabe que
no mesmo comit você vai incluir eh você
vai melhorar uma ficha e você precisa
reestruturar ou porque nos próximos
comites na sua agenda de eixos a serem
de tarefas a serem resolvidas você vai
precisar daquela reestruturação para
facilitar modificações que vem a seguir
facilitar compreensão por quê porque se
você trabalha no método na na classe
você trabalha outros desenvolvedores eh
vão ler o código fonte e vão alterar o
código fonte né você não é o único owner
daquela classe é importante que você
documente bem estruture bem e senão para
ele ele já vê o o atrapalhar logo cedo
perder em produtividade porque o colega
vai questionar o propósito daquela
classe ou daquele daquele método então
tem a questão da facilidade de
compreensão também um outro objetivo que
assim talvez não seja tão tangível mas
que o desenvolvedor proativo aquele
primeiro personagem aquela primeira
pessoa aquele primeiro tipo de
refatorador que eu mencionei que é o
proativo ele também sabe que a
refaturação ela pode reduzir a a
probabilidade de bugs né então um dos
benefícios que o Fler fala no livro é
que a refaturação ela reduz a
possibilidade de introdução de bugs
então você pode estar com esse objetivo
né seu código anda muito manifestando
muitos bugs e você percebe que uma das
coisas é a má estruturação então de
forma contorna isso então vou refaturar
o código para deixar ele menos propenso
a continuar tendo muitos bugs no futuro
a outra coisa que eu já mencionei é
facilitar a inclusão de uma nova
funcionalidade né como eu tava dizendo
70% das refatorações de acordo com os
estudos ocorrem em conjunto com mudanças
onde você tá o objetivo principal é
incluir uma nova funcionalidade você
pode reorganizar seu código também
quando você tá vendo que a testabilidade
do seu código que você vai alterar ela é
ruim dificulta a implementação dos
testes então você pode por exemplo
quebrar um método longo em vários
métodos para facilitar a criação de eh
testes para cada um desses métodos ao
invés de ter o caso de teste que vai
exercitar todas as possibilidades ali da
daquele método é difícil porque como ele
é fácil difícil de compreender eh pode
até dificultar você checar se você tá
cobrindo todos os casos então você
também pode eh no na com os casos de
teste né então você pode reestruturar
para melhorar ter estabilidade você
também pode ter casos onde como a
melhoria do design pode ter relação com
outro requisito não funcional que não
seja testabilidade compreensividade
monitoridade você pode fazer uma
reestruturação porque você tem um um uma
decisão de design código que tá eh
levando a queda de desempenho então uma
vez um aluno meu aluno na disciplina não
meu aluno mas ele tava fazendo a minha
disciplina em técnicas de modularização
e ele veio ele é era desenvolvedor ele é
dono de uma empresa e ele começou ele
ele falou que o o design dele tava
degradado sobre a ótica de performance e
tal e é um dos problemas que ele
estruturais que ele descobriu problemas
de um design de um método é que uma
consulta ao banco ela seria muito mais
rápida se ela tiver tivesse fora do laço
de um loop do que dentro do laço então
ele fez essa transformação né o
resultado gerado pelo método seria o
mesmo mas ele ganharia em termos de
tempo de execução colocando essa
consulta fora do código dentro de um
laço então você pode melhorar ter em
vista eu ten um problema claro aqui de
desempenho então eu vou refaturar para
melhorar esse problema de desempenho e
também isso pode estar como eu di como
eu como eu disse que refatoração pode
ocorrer em diferentes artefatos você
pode notar que você tá tendo muita
dificuldade de fazer manutenção ao seu
banco de dados e pode ser que o problema
seja o próprio esquema conceitual do
banco de dados então você tem um
problema claro que é uma má decomposição
dos dados no modelo de dados e aí você
vai fazer uma reestruturação com o
objetivo de melhorar a manutenção do
banco do eh as alterações que vão ser
feitas no futuro sobre bancos de dados
presente ou futuro sobre bancos de dados
o que que determina a importância quando
é quando você realmente tem um objetivo
muito claro na graduação eu dou uma
disciplina onde os alunos uma das
tarefas é realizar eh refatoração em
projetos código aberto então no semestre
passado eles usaram dois projetos o
Elastic Search e o Press DB e aí foi
engraçado que assim eh teve casos de
issos de por requests aceitos mas teve
uma refaturação que o aluno fez que
tinha o seu mérito vamos dizer assim ela
melhorava a compreensão ligeiramente do
código fonte só que era uma classe nada
tocado só uma pessoa era responsável
fazia modificação nela e assim melhorava
um pouquinho a compreensão mas aí o acho
que era do Elastic Surge ó o o revisor
do código fonte o revisor da
contribuição ele disse o seguinte: "Olha
a refatoração tecnicamente tá correta
mas a inclusão dela não traz um
benefício grande porque não vai não vai
aumentar a produtividade de quem de fato
mantém esse código fonte não vai então é
importante isso caracterizar os
benefícios da refatoração a gente vê que
em estudos que a vasta a maioria dos
macheiros dos esmelos dos problemas
micro e macroproas estruturais do código
fonte eles não são refatorados e aí a
gente vê duas atitudes que geralmente o
desenvolvedor ele vai ele tende a
aplicar as atividades de refaturação em
código com múltipla com múltiplos
problemas estruturais por exemplo god
classure envou métodos com múltiplos
problemas além de ser longo ele tem uma
fit env então eh propositadamente ou não
porque a gente não sabe a intenção do
desenvolvedor mas a gente vê que a
maioria das refatizações elas incidem
sobre classes métodos ou pacotes que têm
múltiplos problemas estruturais uma das
nossas hipóteses é que cada tipo de
problema estrutural por exemplo pega um
long method e aí pega um feature inv ele
junto quando ocorre junto significa um
problema mais sério então por exemplo no
caso do long method o método ele pode
ser longo ele pode ter muitas linhas mas
se você raciocinasse só sobre ele você
poderia chegar à conclusão que olha um
método longo mas o algoritmo ele tem que
ficar aí o algoritmo você consegue
compreender bem se ele fica aí dentro
até 100 linhas de código 50 a lógica tá
aí e agora quando você tem uma feature
em V já é um indício extra de que tem
algo errado de fato errado com aquele
método aquele método não é só longo
fisicamente mas ele tá usando muitos
dados de outra classe e não daquela
classe então eu acredito que tem esse
fator não é só o único fator que explica
mas há uma tendência do desenvolvedor
refatorar eh classes que métodos que não
tem só um smell mas múltiplos smells
eh Alessandro você já comentou isso no
outra resposta mas só estendendo um
pouco a discussão né é já deu para
entender que um design o design ele não
necessariamente é uma classe ele não é
um método ou é uma feature né como você
mencionou em linhas de produtos né
design abstração então nesse contexto eu
posso dizer que refatorações por exemplo
mais grandiosas como vou extrair um
serviço do meu código né tenho esse meu
projeto eu quero extrair um serviço e
torná-lo um microsserviço esse tipo de
modificação a gente pode também chamar
de refatoração ou terminologicamente não
faz
sentido então eh Gustavo boa pergunta eh
cada refatoração ela é um conjunto de
modificações que realmente a gente visa
melhorar o design né a gente pode ser o
design tem a ver com decisões né você
depõe depõe também em termos de
componentes a decisão de usar um estilo
arquitetural então você quando escolhe
por exemplo você pode escolher o MVC mas
você pode escolher o estilo arquitetural
em camadas e essa decisão pode se provar
errada com o tempo parece ser a melhor
escolha a melhor decisão né a melhor
decisão de design naquele momento mas
com o tempo ela pode se mostrar incerta
né muitas pessoas usam o estilo
arquitetural porque tá na moda por
exemplo você citou eh microsserviços
serviços né aí você tem muitas empresas
que assim adaptarem as novas tecnologias
acabam migrando para uma arquitetura de
microsserviços às vezes sem uma análise
ampla né da das vantagens e desvantagens
dessa escolha mas o que a gente observa
em projetos é que existem sim essas
refatorações maiores se são eh um
conjunto de modificações onde se visa
melhorar só o design então a gente pode
enxergar ela com uma refaturação mais
complexa decomposta um conjunto de
refatorações menores se você vai extrair
um microsserviço o que que acontece
muitas vezes é quer na verdade o
comportamento é o mesmo mas você quer
reestruturar oferecer aquela
funcionalidade como um serviço
obviamente vão haver novas decisões de
design que a forma de modularizar como
serviço não é a mesma forma de como
modularizar orientado objetos em classes
então pode ter decisões peculiares aí
mas vão ser transformações ainda o o a
interface que era provida por aquele
módulo aquela funcionalidade é é a mesma
mas agora é uma interface direta
disponível no contexto distribuído então
ele pode ser sim visto como a
refatoração deixa de ser refatoração na
minha opinião quando você quer na
verdade é é você vai ter fazer umas
reestruturações mas o objetivo é
aumentar a funcionalidade incluir nova
funcionalidade tão uma funcionalidade de
X sei lá de auditoria que você vai
tornar ele um microsserviço mas você
também tá fazendo isso porque você quer
colocar mais funcionalidades o cara ele
tá querendo eh na verdade dispor de mais
métodos na interface né então quando a
intenção é essa não é bem melhorar o
design é mais vamos dizer assim oferecer
mais possibilidades pro pro programador
mais funcionalidade pro programador
outro caso é troca de frameworks né por
exemplo se você tem um um framework caso
do framework é interessante porque o
framework ele tem um grande impacto
sobre a arquitetura o design ele gera
restrições ao design então quando você
escolhe um framework junto você tá
reusando as decisões de design as
decisões de arquiteturais daquele framer
aí eu vejo dois casos se a troca do
frame eh basicamente oferece os mesmos
serviços mas a arquitetura imposta as
decisões de design impostas por aquele
frame se mostram inadequadas em algum
momento ao longo da evolução aí você
troca o framework com objetivo de
melhorar o design mas sem querer mudar
comportamento aí é uma refaturação agora
quando você é troca um frameor porque
ele tem novas funcionalidades porque ele
permite outros usava um frameor de
persistência X agora você vai usar um Y
mas não porque a arquitetura daquele
framer quer dizer as decisões de design
daquele framework é ruins mas porque ele
fornece mais eh possibilidade de formas
de automatizar transação fazer rollback
de que o anterior era muito primitivo
não tinha essas funcionalidades não
tinha essas possibilidades aí eu diria
que obviamente vai ter um impacto no
design mas é o objetivo não foi melhorar
o design então eu vejo esses casos como
um outro cenário é extração do de um
módulo né do seu código se não é código
morto eu eu diria que você tá retirando
funcionalidade você pode até que faz
aplicar algumas transformações
estruturais mas ali o seu objetivo era
tirar uma funcionalidade pode ser que é
parte desse processo tenha algumas
refatorações mas o objetivo ali era
reduzir funcionalidade então não diria
que tirar o módulo ele pelo fato de
distinguir aquela funcionalidade do
código fonte ela seja uma refaturação é
atrelado a esses comentários que eu fiz
é importante notar que às vezes é
realmente difícil segregar quando eu tô
fazendo refatoração e quando eu tô
fazendo outras atividades de mudança
porque o que acontece muitas vezes é que
a gente tá fazendo as duas coisas ao
mesmo tempo talvez um objetivo dominante
né que seja sei lá incluir uma nova
funcionalidade mas pode ser que ao longo
do processo porque tem mudanças que às
vezes duram meses né você vê você estuda
os projetos open source empurre quest
até ele ser aceito leva 2 meses 3 meses
4 meses né desde que começou alguém o
proponente houve uma primeira proposição
de uma mudança para resolver aquela
tarefa até o currículo demorar meses a
gente fez um estudo onde a gente ficou
analisando as discussões dos
desenvolvedores desde o início da
mudança primeira proposta de mudança até
a aceitação do P request é muito
interessante como na ISO objetivo era um
claro sei lá era adicionar uma nova
feature ou corrigir um bug e ao longo do
processo desenvolvedores vão observando
outros problemas no Código fonte
observando que outras tarefas como
refaturação são necessárias para
alcançar aquele macroobjetivo ou pode
ser que você tenha três objetivos em
paralelo mesmo né que vão além do que tá
na na ISO lógico a boa prática diz que
você deveria fazer um comiteta para
resolver aquela aquela tarefa mas
naturalmente acontece de que você vai
introduzir um código fonte aí você
estrutura mal o código fonte e chegou um
revisor um colaborador e diz: "Não você
tem que reestruturar porque é dessa
forma não tá bem decomposto os métodos
dessa classe e tal" eu diria assim que
não é é possível desassociar essas
coisas então as pessoas fazem
modificações com objetivo de melhorar o
design mas às vezes eh não dá para ser
se você olha para um comite você vai
falar se teve refatoração ou não sem
participar do processo muitas vezes até
difícil desassociar porque ele pode ter
feito ali
refatorações mas como você vê a sua
janela o código final gerado você não
vai saber porque realmente muitas vezes
a a refatoração entrecorta as outras
modificações que são feitas né no mesmo
comite
então Alessandro por tudo que você falou
pra gente até agora né fica claro que
refator tá na agenda do desenvolvedor né
pelo que você observa nos seus trabalhos
refaturar está na agenda do
desenvolvedor mas o quão comum é os
desenvolvedores refatorem código ou será
que se fala muito e se faz pouco eu
acredito que muitas vezes tá na agenda
do desenvolvedor né eh hoje com boa
parte das empresas adotando métodos
ágeis e também
adotando esse modelo de
desenvolvimento a Laget Hubas Software
Development quando você tem pessoas
múltiplas múltiplos desenvolvedores
contribuindo para uma única modificação
para um único comite revisando o código
fonte acaba se tornando parte da agência
não explicitamente mas de forma reativa
também porque vai ter outros olhos
olhando para aquele código fonte
julgando
ou não e é engraçado que tem tem um
estudo não muito recente mas um estudo
que foi publicado pelo pessoal da FMG
Marco Tul colegas no sistema brasileiro
de sistema de informação que ele que
eles mostram que a maioria das se eu não
me engano cerca de 40% se eu não me
engano das da das razões por rejeição de
por request estão relacionados com
design então para quem trabalha nesse
modo desenvolvimento colaborativo acaba
isso sendo parte natural da agenda agora
existem diferentes situações tem
sistemas que eu conheço que eles são
construídos para realmente já serem
usados por uma única pessoa e serem
usados a curto prazo por exemplo tem
projetos que a gente eh realiza não vou
falar o nome da empresa mas é uma
empresa grande onde ela tem um setor
onde ela faz muito projetos com academia
e tem muitos sistemas são construídos
para durar 6 meses para durar um ano ou
ele é parte de um projeto de pesquisa
ele de fato vai ser concluído naquele
espaço de tempo um mês 2 meses três
meses então no caso desses
desenvolvedores não necessariamente a
refatoração é parte da agenda eu também
vejo um outro cenário seguinte que já
aconteceu em aluno com aluno meu
trabalhando de caso numa startup aqui no
Rio de Janeiro de eh sistema ser
construído sem qualquer preocupação em
manter a saúde do design vai virando um
monolito um sistema muito mal
estruturado aí a empresa que contratou o
desenvolvimento a usuário ou cliente
contratou o desenvolvimento tá vendo que
a empresa que desenvolveu tá demorando
muito para atender as demandas de
manutenção resolver as e começa a
questionar a eficácia eficiência daquela
organização então ocorre casos por
exemplo como caso dessa startup dela
receber um projeto que foi desenvolvido
aparente com pouca nenhuma preocupação
com a qualidade do design mas um código
assim realmente monolito mal estruturado
código espaguete e ela é paga ela é é e
o investimento daquela organização é
justamente para rejuvenescer o código
fonte que é de um sistema que foi
construído com com desenvolvedores
aparentemente sem refatoração na agenda
então eu diria assim que nem sempre tá
na agenda do desenvolvedor mas eu acho
que bons engenheiros de software na
maioria dos contextos onde a ideia que o
software dure por muito tempo tem um
tempo de vida longo é isso acaba eh de
uma forma de outra fazendo parte da
agenda eu vejo muitos sistemas fechados
que diferente de projetos open source
onde refaturação aparece de forma
homogênea ao longo do da história né dos
comites do do sistema eu vejo
organizações que não se preocupam com o
design ou refatorar até um determinado
ponto mas aí não tem jeito aí vai mexer
num código que ele imaginava que num
modo que ele imaginava que não ia mexer
mas os requisitos são difíceis de serem
preditos né então aí acaba que tem que
acabar eh eh gastando bastante tempo
reestruturando parte do software não era
parte da agenda antes mas devido à novas
demandas devido os requisitos que
aparecem acaba fazendo parte da agenda
eu eu eu diria assim se é comum os
desenvolvedores refatorarem o código
fonte acho que varia de projeto para
projeto e de novo tá muito relacionado
com o quão o desenvolvedor já sabe que
vai manter vai ter que modificar aquele
código fonte ou aquele código vai ser
lido por alguém as razões para refatorar
como eu disse os objetivos são os mais
variados mas acho que um uma coisa que
tem que ser esclarecida principalmente
para as pessoas que estão entrando na
área ou desenvolvedores talvez não tenha
tanto experiência desenvolvedores
novatos é que eh não é assim não precisa
necessariamente ter um smell de CO um
dos conhecidos por exemplo catálogo do
follow uma classe grande um mestro
grande não precisa ser o problema
estrutural o problema do design não
precisa ser Smel catalogado porque tem
muitos problemas de design mesmo gerais
que não estão catalogados na web ou não
ou não tão num livro mas talvez um esmel
específico ali do do tipo de arquitetura
do domínio né um esmel do domínio então
a refaturação ela pode ocorrer não
necessariamente quando é para resolver
um problema de design associado com
problemas com eh smells clássicos ou tão
catalogados em algum lugar
então Alessandro conversando com o
Marcelo Maia no nosso último episódio a
gente falou bastante sobre Code Smells
né que refatoração tá muito alinhado ali
com Cels e uma das coisas que o Marcelo
mencionou era que se o desenvolvedor não
tiver apoiado por testes automatizados
uma refatoração para remover um possível
coach mel pode acabar sendo um tiro no
pé né o cara vai refatorar e acaba que
insere um bug por que que isso acontece
né é difícil refaturar tem refatorações
que são desafiadoras
excelente pergunta eu diria antes de de
mais nada que qualquer modificação que
você faça no programa sem a presença de
teste traz risco pode ser refatoração
pode ser você incluir uma nova feature
pode ser você corrigir um bug toda e
qualquer mudança ela traz risco se você
não tem os testes adequados para eh
garantir que o comportamento real do
programa as após as
modificações eh ela corresponde ao
comportamento esperado então isso é meio
que inerente a qualquer mudança o lado
dessa pergunta é: será que a refatoração
sem testes sem a presença de testes que
cobrem o código a ser refatorado são
adequados ão a cobertura razoável código
sendo refaturado ela é mais arriscada do
que outros tipos de mudança eu diria que
primeiro realmente tem que ter teste é
tanto que se você e isso também acontece
com os alunos lá da graduação que
trabalham em adicionar se você não tem
os testes se você escreve se você
refatória o código e você não reflete
antes o que precisa ser alterado no
código de teste devido aquela
reestruturação ou não e não cria novos
casos de teste que são necessários o seu
a sua contribuição vai ser rejeitada
então é super importante mais nada na
minha opinião bom engenheiro ele tem que
primeiro antes de começar a executar
isso como qualquer na minha opinião como
programação em geral né qualquer
modificação qualquer módulo que você
inclui eu acho que você deve pensar na
específica porque o teste não é
especificação né mas o teste ele traz
traz alguns exemplos associados com a
especificação daquele módulo então uma
especificação vamos dizer assim parcial
então acho que é importante escrever eh
os testes os testes antes né e ter
testes primo que eu escreva antes ela
refator primeiro mas em algum momento
mas o ideal acho que era primeiro mais
nada pensar sobre os testes até porque
se eh isso é importante porque antes de
começar a fazer a refaturação se você já
planeja os testes você pode chegar à
conclusão que é difícil escrever os
testes para para devido aquela nova
reestruturação e num tempo que eu tenho
disponível né então primeiro é
importante planejar os testes é
importante escrever os testes e isso
pode até eh ser um
impeditivo eh por exemplo se a cobertura
tem que ser maior ou pode ser um
impeditivo o desenvolvedor falou: "Ó
isso aqui talvez o o custo que eu vou
ter reestruturando mais escrever os
testes não compensa o benefício que eu
gostaria de ter." Então esse é algo
importante tem alguns estudos aí que
dizem que alguns tipos de refaturação
induzem ou introduzem bugs com
frequência eu diria assim que esses
estudos são interessantes mas eu acho
que a gente tem ainda uma longa
trajetória para entender isso por quê a
metodologia que esses estudos usam para
relacionar o bug com a refaturação são
ainda e é importante que tenham essas
metodologias mas a gente precisa de
aperfeiçoar para realmente saber se as
refaturações introduzem bugs geralmente
eles são eh eles olham pro seguinte: ah
se ocorreu um bug naquele elemento que
foi fatorado então independente do ponto
da história então tem relação tem outras
metodologias que olham a ocorrência ah
eh se ocorreu no mesmo comit o bug então
o o refatoração induziu às vezes usa até
a palavra introduziu o bug como a gente
sabe por exemplo pega o extract method o
extract method que é um dos estudos diz
que é uma refatoração que e induz ou
introduz bug é questionável de acordo
com essa metodologia utilizada se foi
ele que de fato que introduziu porque o
Strack Métod de acordo com estudos ele é
o que ocorre praticamente não vou dizer
todas as vezes mas 80% das vezes que
você usa extract method é numa mudança
que tem um outro propósito que não
melhorar o design é introduzir uma
feature é ajudar na correção de um bug
então só pelo fato de ter ocorrido no
mesmo comit eu não sei a minha opinião é
que não dá para afirmar que o extract
method é a o mecânicas os passos que se
segue para implementar o stract method
que é selecionar o código fonte do o
método de origem que vai ser extraído
criar declarar um novo método e e
arrastar mover o código que foi
selecionado pro novo método e atualizar
os clientes e isso foi o que introduziu
bug se ele tá ocorrendo com outras
mudanças né então isso é muito difícil
de dizer um estudo que uma aluna minha
realizou no passado ela tentou replicar
a gente não confiava muito na
metodologia e a gente tentou replicar o
estudo mas aí tendo uma análise caso a
caso tipo pegava lá o o a a a mudança
que incluia o refactoring ou só o ref se
fosse uma um comit que só envolvia
refactoring via a descrição do bug e vi
e entendia olhava pra correção e via
essa refaturação de tinha uma relação na
maioria dos casos que a gente pegou foi
uma amostra pequena de 200 300 casos mas
a gente não via essa relação né no nos
mesmos projetos que um um estudo eh
tinha sido feito anteriormente aí a
gente que acabou bom então é difícil
dizer aparentemente pode ser que não
tenha acontecido o que que a gente fez a
gente seguiu uma metodologia diferente
olha vamos ver no fall o folder diz o
seguinte fer diz que um dos objetivos de
refaturar que eu falei mencionei
mencione anteriormente é reduzir a
propensão de bugs no futuro então em vez
de dizer coisas do tipo ah o refactor
introduziu bug ou induziu um bug de
acordo com as metodologias existentes
era muito difícil dizer vamos comparar
as classes que sofreram refatoração com
as que não sofreram refatoração e ver a
distância em termos de números de comits
que tocaram naquelas classes com a
ocorrência de um bug e a gente viu que a
distância do comit onde foi introduzido
o bug para a a o a a refatoração da
classe era muito maior do que eh a a
você pegasse uma classe que não foi
refatorada você observava o bug e olhava
pras pras últimas mudanças né então a a
distância era muito grande então a gente
praticamente não encontrou caso muito
pouco caso com distância um ou dois se
número de comites refaturou no commit aí
no próximo comit observou um bug um bug
foi introduzido ou a cada depois de dois
comites geralmente a distância era muito
grande a classe recebia várias
modificações sei lá sete oito e aí assim
então a gente não ainda assim o nosso
método não dá para dizer que tem as suas
imperfeições né tem seus problemas não
dá para dizer que refaturação de fato eh
reduz a probabilidade de bugs mas esse
estudo inicial que foi publicado como
poster aí a Luna teve foi para foi pro
Canadá e a gente tem um artigo de jorno
pronto que falta na verdade submetê-lo
mas tem que fazer ajuste é a gente
observou isso que a distância entre a
introdução de bug em termos de número de
comit que tocaram a classe e aquela
classe quando aquela classe foi
refaturada é bastante extenso então eu
eu diria que hoje eu não posso confiar
ter muita confiança sobre essa afirmação
que refatorações são tipos de mudanças
que eh introduzem bugs no sentido de
mais do que outras porque qualquer
mudança tem risco de se introduzirem
mudança então eh eu diria isso mas o o
ponto que o que é diferente do que o
Marcelo falou de fato eu concordo com
ele se você não tem os testes
automatizados é um risco muito alto mas
é isso na minha opinião é para qualquer
mudança alessandro quais práticas de
desenvolvimento de software podem apoiar
os desenvolvedores que gostam de
refaturar código e qual é o status atual
das ferramentas de refatoração dá para
confiar nelas será que elas dão mais
trabalho do que ajudam
e aí tá gostando do nosso bate-papo
sobre refatoração com o Alessandro
Garcia essa primeira parte foi mais
introdutória e motivacional na segunda
parte vamos falar de algumas coisas mais
avançadas como práticas que apoiam
refatoração o status atual das
ferramentas de refatoração inclusive um
negócio chamado bat refactoring você
sabe o que que é um batoring fica ligado
na segunda parte que a gente vai
explicar ciao ciao
esse podcast foi editado pela produtora
Reis m