Olá, hoje a gente vai dar uma olhada num assunto chave para
quem desenvolve software, os codes mels.
Sabe aqueles maus cheiros no código?
Isso. Nossa base aqui é um material
bem legal do livro engenharia de software Moderna.
A ideia é entender esses indicadores, né?
Para saber onde o código talvez precise de um trato, para
facilitar a manutenção, a evolução.
Enfim, vamos investigar isso. Exato, e é bom definir, né?
Formalmente, codes mels são tipo.
Sinais de alerta eles indicam que pode haver um problema ali,
dificuldade de manter e de entender e de mudar, testar.
Mas olha, é super importante lembrar, são indicadores.
Não é porque tem o cheiro que você tem que sair refaturando
loucamente. Depende.
Sabe quão importante é aquele trecho?
Mexe muito nele. Certo, o contexto manda e o
material já começa forte com o código duplicado.
Ele coloca como Oo vilão principal, talvez o mais comum e
danoso. É um clássico, pior que é.
E não é só o retrabalho, né? É o risco de de inconsistência
que isso gera. Imagina num projeto grande?
Nossa, total. E o interessante é que essa
duplicação ela ela nem sempre é óbvia.
Assim, na cara existem os tais clones, né?
Ah, sim. Tem o tipo um que é igualzinho,
só muda espaço, comentário. O tipo 2 já muda nome de
variável identificador, o tipo 3 tem umas mudancinhas nos
comandos e o tipo 4 que é mais sutil.
Eles fazem a mesma coisa, mas com lógicas diferentes, tipo hã
calcular fatorial interativo e recursivo.
Entendi o resultado é o mesmo, mas o como é diferente isso para
resolver, geralmente a gente pensa em quê?
Extração de método para tirar o trecho comum, ou extração de
classe se for algo maior, ou até o pulop metal, se tiver a ver
com herança. E olha só, um estudo de 2013 que
o livro cita, com 85 desenvolvedores, mostrou que
código duplicado era a maior preocupação deles mesmo.
Faz sentido o que nos leva para outro cheiro bem conhecido.
Métodos longos quem nunca, não é?
Abriu um método e foi rolando. Rolando.
Pois é, a regra geral é. Métodos pequenos e focados, uma
responsabilidade só. Idealmente quando fica muito
longo é é complicado de entender, de testar, de dar
manutenção. A solução mais direta geralmente
é extração de método, quebrar aquele monstrinho em pedaços
menores, mais gerenciáveis. É, e não tem um número mágico de
linhas, né? Mas a galera hoje em dia tende a
gostar de métodos mais curtinhos.
Sei lá, menos de 20 linhas, talvez?
Sim, essa é uma referência comum.
Mas, claro, depende da linguagem, do contexto.
Sempre. E o mesmo vale para classes
grandes. A lógica parecida.
Uma classe não devia fazer coisa demais, ter muitas
responsabilidades que não tem muito a ver umas com as outras.
Baixa coesão, né? Exatamente.
Geralmente você vê isso quando tem muitos atributos e eles não
não se conversam muito bem ali dentro.
A solução parecida também. Extração de classe divide a
responsabilidade. Aí que entram as famosas God
classes, os blogs, aquelas classes que sabem tudo, fazem
tudo. Essas mesmas.
Fico pensando se nomes, tipo manager, system controller, se
são sempre um alerta ou só um padrão que às vezes pode levar a
isso. Olha, é um bom, um bom
indicador, com certeza, não é regra.
Mas vale a pena investigar quando você vê esses nomes muito
genéricos? Certo.
E falando em investigar relações entre classes, tem o cheiro.
Com nome ótimo feature and VA inveja de funcionalidades.
Adoro esse nome. É tipo.
O método tá lá numa classe, mas fica o tempo todo chamando coisa
de outra classe, usando mais os dados e métodos de lado que os
seus próprios. É quase como se ele quisesse
morar na outra classe. É bem isso.
A analogia é perfeita. O exemplo conceitual que o livro
dá mostra isso, um método chamando várias coisas de um
objeto de outra classe e quase nada da sua própria uhum mais
sentido na classe invejada. Aí a refaturação é pensar na
movimentação de método. Faz todo o sentido próximo
ponto, métodos com muitos parâmetros.
Ah, sim. A ideia é buscar simplicidade,
clareza. Muitos parâmetros deixam o
método difícil de usar. De entender qual a ordem, o que
cada um faz. É fácil de se perder?
Total e tem 2 saídas principais. Conceitualmente, primeira, será
que algum parâmetro pode ser Descoberto lá dentro do método
tipo, obter o parâmetro p 2 a partir do p um que você já
recebeu? Entendi evitar passar o que pode
ser calculado internamente. Exato, isso.
A segunda é agrupar parâmetros que sempre andam juntos.
Em vez de passar início, fim, fuso, horários separados, talvez
criar um objeto intervalo de tempo, sabe?
Sim. Agrupar parece tão elegante
depois que a gente pensa, simplifica a assinatura do
método para caramba. Exato e por último, mas não
menos importante, variáveis globais.
Ah, essas velhas conhecidas. Pois é, o problema clássico
delas é o acoplamento ruim que geram.
Fica muito difícil entender um pedaço do código isolado, porque
o comportamento dele pode depender de uma variável global
que sabe se lá onde foi alterada.
Imagina depurar isso? Uma função simples f que usa uma
global GO. Resultado de f depende
totalmente do valor de g naquele instante.
EG pode ter sido modificada em qualquer lugar.
É a receita pro pesadelo na hora de achar.
Bug precisamente e. Vale lembrar que atributos
estáticos em Java, por exemplo. Acabou agindo meio como globais,
né? Nesse sentido de estado
compartilhado e acessível de muitos lugares.
Exatamente. O estado global complica demais
o raciocínio sobre o código, essa visibilidade toda.
A chance de alteração vinda de qualquer lugar, introduz uma
complexidade que a gente deveria evitar.
Perfeito, então, resumindo, ficar de olho nesses cheiros,
código duplicado, métodos e classes gigantes, a tal da
inveja. Parâmetros de mais e fugir das
globais parece um ótimo caminho para ter um código mais
saudável, mais fácil de trabalhar, né?
Com certeza é o primeiro passo. Excelente obrigado pela atenção
nessa análise de hoje.