3 Code Smells que Estão Destruindo Seu Código!

[Música] acho que todo mundo já se deparou com código que é difícil de entender né talvez tenha sido você mesmo que escreveu né ele há meses atrás e funcionou bem até agora quando lançaram uma feature nova ali em produção né E foi adicionado por exemplo um status novo e agora começou a bugar tudo aí é aberto um card para você para você analisar né o problema e corrigir e a primeira vista Parece ser bem simples porém quando tu roda o projeto e começa a testar você vê que parece que não vai terminar aí um dia

como você tinha prometido ali na plane né já passou por isso quem nunca né ah agora como que isso acontece né Tem como evitar esse tipo de de situação e por que que é importante a gente entender sobre codes mels tá então eu vou diminuir minha câmera aqui ó já vamos começar pela definição tá essa definição Aqui é do livro A engen software moderna tá vou deixar o link na descrição caso você queira e adquirir Eu recomendo bastante a leitura É bem interessante E aí ele traz uma definição bem simples aqui bem direta tá codes

smel são indicadores de código de baixa qualidade Isto é código difícil de manter entender modificar ou testar em resumo código que não está entre aspas cheirando bem e portanto Talvez possa ser refatorado eu borrei aqui o restante tá é de propósito porque a gente vai voltar nessa definição aqui daqui a pouco e essa parte final aqui né desse trecho da definição ela vai provavelmente mudar um pouco ali a sua leitura sobre codes mels né talvez você conheça os codes mels mas ess essa definição né vamos dizer assim que o autor traz aqui eu achei bem

interessante compartilhar com vocês daqui a pouco a gente vai voltar nela tá mas enquanto isso vamos lá Vamos definir algumas coisas aqui sobre codes mels tá trouxe uma trouxe né uma forma diferente aqui da gente poder abordar esse tipo de assunto e eu vou trazer aqui os principais né os três principais codes mels que na minha opinião são os mais ah perigosos vamos dizer assim tá primeiro deles obviamente né acho que você já deve ter saber e talvez você vai até concordar comigo que para mim o pior de todos é o código duplicado tá Por

quê a gente vai ver o porquê aqui mas basicamente né quando a gente tem o código duplicado a gente vai precisar né quando é necessário dar manutenção nesse trecho né nessa regra por exemplo Principalmente quando é regra aí é pior ainda a gente vai ter que dar dar manutenção em vários locais eh diferentes O problema é que à medida que o software ele vai crescendo e vai tendo mais locais onde tá sendo duplicado aquele código talvez você alguém que é que entrou novo ali no no projeto talvez não lembre que tenha uma parte do sistema

que tá né que tem essa regra ainda você altera em algumas e deixa algumas ali eh da forma que tá E aí vai começar a ter problemas para todo lado né bom e pega pega esse exemplo aqui para você para você ver se faz sentido né aí no seu contexto imagina que você ten um sistema ali que existe em status né pode ser status de de sei lá de usuário de produto enfim supor que a gente tenha Unos status ali de a aprovado tem um status de reprovado e tem um status de por exemplo em

análise beleza aí você vai lá né você cria umas constantes por exemplo um objeto que vai eh guardar esses valores aqui vamos supor que o aprovado seja um aqui seja dois e isso aqui seja Três beleza tranquilo e você vai lá cria uma constante como eu falei e sai o utilizando né ah se tá aprovado você checa né se o status que vem por exemplo da iepi lá o status ah ID é igual igual igual a reprovado ou aprovado por tanto faz né supor que aí você tem um um objeto aqui uma constante aqui né

A tá lá a a [Música] provado Beleza o que acontece aqui essa regra funciona bem certo aí se você tem outro ponto da aplicação que vai utilizar isso aqui Provavelmente você vai copiar esse mesmo trecho aqui é um trecho aparentemente inofensivo certo porém o que acontece se no futuro né talvez aí no próximo mês a gente tem agora não só o status aprovado a gente tem agora também por exemplo um status a gente quebre esse status aprovado em dois aí vai ter por exemplo status aprovado automático e um aprovado manual por exemplo o que que

vai acontecer aqui então esse status aqui por exemplo ele vai virar dois é o aprovado manual manual e o aprovado automático beleza aí agora isso aqui vai ser por exemplo o status 1 Isso aqui vai ser o status 4 eita ficou no cantinho aqui status 4 1 e 4 Beleza então esse um aqui não existe mais primeiro ponto você vai ter que fazer um reflector aqui certo porque esse aprovado ele já não existe agora é só aprovado manual ou automático certo vamos supor que nesse ponto você precisa validar se é um ou outro beleza então

agora o aprovado como ele é se se quebrou né se dividiu em dois você vai ter que fazer essa checagem vai ter que fazer esse refactory e vai ter que alterar essa checagem aqui o problema é imagina agora que você tenha esse tipo de checagem aqui em vários pontos da aplicação várias páginas em várias telas é primeiro que você vai ter que fazer esse refectory Em vários pontos né e segundo que vamos supor que você fez o refectory Conseguiu resolver tudo Porém você ainda tá sustiva a esse tipo de coisa acontecer novamente com reprovado com

análise vamos supor que apareça mais status aqui né são exemplos simples mas já dá para você entender o problema disso aqui né então qual seria uma forma né correta vamos dizer assim de resolver isso daqui você poderia simplesmente colocar isso daqui ah em uma classe né E você poderia e ter ter um método né que vai ser is approved aí você passa um status para ele aqui por exemplo ou ou no Construtor ou direto aqui no método aí né tanto faz a questão de implementação E aí esse status aqui esse método Na verdade ele vai

ser o cara que vai ser vai ser sempre a fonte da Verdade vamos dizer assim porque toda vez que tiver um um um status novo de aprovado você adiciona essa checagem aqui e aí todo o lugar da aplicação em vez de estar usando isso aqui direto a gente descarta isso daqui e começa a usar só o método Fechou então isso é o primeiro codes mels né vamos dizer assim que é o duplicação né Beleza o segundo né que para mim também é extremamente importante ali pra gente entender ah é o quando a gente tem classes

né ou componentes que são muito grandes isso aqui também é alo explicativo o nome né então você tem lá uma classe de sei lá 300 linhas ou mais ou um componente de 400 ou mais linhas e aí por que que isso é considerado um cod smel né basicamente pela dificuldade que a gente tem de entender um uma classe ou um componente uma função enfim que seja muito grande né pode até que tá tudo correto vamos dizer assim lá dentro você tá aplicando o single responsability principle e etc ah porém pelo fato Dee ser né verticalmente

ali muito longo o problema disso é que quando você precisa dar manutenção você tem que mexer em vários vários várias partes de alguns métodos ali algumas funções ali internas ou componentes menores ali dentro você começa a ter um pouco de dificuldade até questão de de entendimento né Principalmente né na verdade de entendimento que aí também é um sinal de complexidade que chama o cognitive load que quando a gente tem essa carga cognitiva né para você entender algo e ela é muito alta tá e inclusive até voltando aqui no duplicação Esse aqui também ele tem um

sintoma né Ele é um sintoma de complexidade que é o Change ah amplification amplif ampli fication Tá o que que isso aqui quer dizer quer dizer o seguinte quando você tem que fazer uma alteração essa alteração ela começa a se propagar em vários pontos da aplicação que é esse exemplo que a gente tinha e mostrado aqui certo quando você começa a ter esse tipo de validação todo ponto da aplicação que tem esse tipo de coisa você vai ter que fazer o refectory então e a modificação que poderia ser num ponto único ela começa a ser

em vários pontos da aplicação certo agora voltando a a parte de classes né classes grandes pode ser classes aqui ou ou componentes funções tá isso vale para qualquer um ele também tem esse ponto tá el também é um sinal de complexidade né que é o cognitive load eu até recomendo n caso você ten interesse para dar uma pesquisada que é bem interessante esse assunto cognitive load tá ã e existem vários patterns né que a gente tem ali pra gente conseguir contornar esse tipo de codes Mel tá por exemplo no react a gente consegue utilizar o

composition basicamente a gente quebra né os componentes ali vamos supor que você tem um componente muito grande né Tem um componente muito complexo aqui você vai quebrar ele em vários componentes menores que aí a gente vai compondo esses componentes à medida que a gente precisa tá então sob medida vamos dizer assim então você vai vai n Você tem o componente base e você vai acoplando ali os componentes que forem necessários né Inclusive tem vídeos aqui no canal sobre esse esse esse design pattern né dentro do do react inclusive se eu lembrar Vou deixar na descrição

para você dar uma olhadinha depois beleza e o último aqui que a gente vai tratar no vídeo né É É sobre obsessão de primitivos né obsessão por primitivos o que que isso quer dizer quer dizer o seguinte a gente né tende né geralmente a quando a gente vai definir algum formato de de um objeto por exemplo a gente tende a a sempre ir pelo lado dos primitivos ou seja utilizar um Number utilizar um string utilizar um bullan E por aí vai só que qual que é o problema disso nem sempre né o correto seria utilização

de um primitivo por quê eh existem cenários Por exemplo quando a gente tem um CPF imagina um CPF geralmente quando a gente tem um CPF a gente ah vai ter geralmente né a gente vai ter algum tipo de validação desse CPF e o CPF ele a gente vai tratar ele como string certo porém se a gente utilizar ele sempre como um string simples é um string simples pode ser qualquer coisa você pode né talvez limitar ali quantidade de caracteres enfim mas você não não vai fazer essa validação mais profunda do CPF caso seja necessário aí

já é interessante a gente partir para uma outra abordagem que inclusive já resolve esse problema ali do ddsm né que é obsessão por primitivos até colocar aqui ó obsessão por primitivos beleza e aí vamos supor que a gente tem ali um CPF tá E aí esse CPF como a gente como eu falei né a gente vai geralmente vai tratar ele como string tá só que se ele tiver começar a ter muitas validações e etc é interessante a gente utilizar uma classe tá Por quê quando a gente utiliza uma classe nesse caso aqui a gente pode

fazer o encapsulamento dessas validações e etc né em cima do do CPF e calculando por exemplo o o dígito verificador enfim né o tamanho da da string e etc e aí no DDD isso é chamado né de velho objects então se você já estuda DDD e etc é um ponto ali interessante que os Vel objects Eles já resolvem esse codes Mel né que é obsessão por primitivos uma vez que a gente pode por exemplo como eu falei criar uma classe CPF tá E essa classe CPF ela vai fazer né Toda vez que você precisar instanciar

um CPF você pega a string que você recebeu e passa para essa classe e essa classe ela vai fazer a instanciação se tiver correta então você sempre preserva o estado válido né ali daquela informação isso é muito útil tá isso Vale também para por exemplo coordenadas para nomes se você tiver validação nos nomes também idade enfim né tudo que você precisa de algum tipo de de regra né Aí você encapsula isso dentro de uma classe beleza tá a gente falou né sobre os co mels falou sobre alguns algumas formas que a gente tem de de

corrigir eles né inclusive vou até deixar o nome aqui ó aqui os velho objects objects do DDD tá para você dar uma pesquisada depois caso tenha interesse né até deixa nos comentários aí que eu posso trazer um vídeo sobre isso bom como é que a gente previne né esse tipo de esse aqui são soluções né caso já né a gente já tem esse tipo de coisa ou a gente consegue contornar através desses ah diminuir um pouco aqui ó desses codos melos que a gente tratou aqui certo porém ah Existe alguma forma da gente prevenir isso

tá E aí a gente volta né eu vou voltar aqui pra gente tratar agora do da segunda parte tá bom na definição aqui de cima né o termo indicadores significa que não devemos considerar que todo cmel deve ser imediatamente refatorado essa decisão Depende de outro de outros fatores como a importância do trecho de código e a frequência com que ele precisar precisará ser mantido tá isso aqui muda o jogo tá por qu quando a gente vê começa a estudar sobre coos melos a a vontade que tem é sair refatorando todo o projeto de uma vez

certo só que não é assim que né funciona no dia a dia então como é que a gente trata esse tipo de de situação você vai definir né você vai analisar ali junto com o seu time quais são né esses pontos mais cruciais ali da sua aplicação e daí você consegue você e seu time consegue analisar Quais são os códigos ali que vocês devem atacar primeiro Tá então não é porque você viu um codes Mel Ali você vai sair refaturar ele imediatamente tá pode ser né nesse esses casos Por exemplo quando a gente tá tem

código duplicado é leva tempo né para você analisar todos os lugares que esse que esse código duplicado ele tá né ele ele está você precisa identificar isso primeiro e depois você precisa fazer muitos testes ali em cima para que não quebre né nada que já tava funcionando antes e aí que entra a parte de como é que a gente previne esse tipo de de situação tá bom a primeira forma né Eh que inclusive tá aqui na na definição né vou até aqui voltar aqui ó então aqui ó são códigos que são difícil de manter entender

modificar ou testar Então a primeira forma de você conseguir a mitigar ali e evitar os codes mels são exatamente os testes tá quando você tem um um projeto que ele tá utilizando testes primeiro que fica mais fácil de você dar manutenção Então você fazer os refos e você fica mais você tem mais confiança hum seja um Júnior que tá entrando no projeto agora ou seja um Senor enfim não tem diferença porque Ah você consegue ter uma tranquilidade na hora que você vai alterar o código porque se você fizer algo que que quebre o teste ele

vai te avisar tá então você tem esse feedback instantâneo ali isso ajuda demais né e traz m a confiança pro time primeiro esse esse é o primeiro ponto segundo ponto é code review então é extremamente importante você fazer o Code review dos seus pares tá E além disso você ser ah crítico também tá crítico no que eu falo falo né tanto no seu código que você tá escrevendo quanto no código dos seus Paes e e crítica em relação em relação ao código tá não a pessoa em si por quê isso traz né Isso vai gerar

um ciclo Virtuoso no time onde quando você eh for avaliar o código de alguém você tenta ser o mais criterioso possível claro né medida do do do possível E também levando o bom senso ali eh em consideração ã Além disso né Tem a parte da documentação tá então a documentação quando eu falo documentação não necessariamente é sei lá um arquivo ali né uma página ali no confluence da vida alguma coisa assim mas ah o próprio código o próprio código ele já é uma documentação viva né um código bem escrito ele já é uma documentação viva

principalmente se diver teste porque o teste ele vai né dizer ali por exemplo e os casos de teste eles vão dizer para você qual que é o cenário e o que que deve acontecer naquele dat cenário então né já já dispensa ali várias páginas e páginas ali de de texto num confluência explicando o que que aquele trecho tá fazendo tá Ah esses são alguns de muitos codes mels tá você curtiu deixa aqui o seu like tá e para fechar eu deixo um desafio para você bom o desafio é analise o seu código que você escreveu

ontem veja se você consegue ali identificar algum desses cdigos mhos que a gente tratou aqui seja crítico com o seu código e com o código dos seus pares como eu comentei isso vai gerar um ciclo Virtuoso no time né e melhorar a qualidade do projeto o que vai também gerar um ambiente muito melhor de se trabalhar né não tem nada pior no projeto do que código ruim que te dá dor de cabeça dá problemas problema direto em produção enfim né ah e os links aqui do do dos livros estão na descrição caso você tenha interesse

tá Inclusive o de engenharia moderna do Marco tullio e também do Factory do Martin Fer Beleza então é isso galera Valeu falou grande abraço e até a próxima