Olá sejam bem-vindos ao canal engenharia de software com ênfase ou ml Eu sou professor Denis GS e eu já atuo na área de modelagem de software há vários anos eu tenho quatro vídeos publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos so modelagem de software utilizando a linguagem uml na aula de hoje eu vou começar a falar sobre o tema de maus cheiros de código que está dentro da da área de verificação e validação Então vamos iniciar a nossa aula Então esta vai ser a primeira aula sobre Mach de código ou
Cold smells Então vamos começar então ma cheos de código são características que se apresentam no código fonte que podem indicar a possibilidade de problemas esses problemas eles não vão surgir imediatamente eles não vão impedir o funcionamento do código ou do software mas são características são eh formas como o código foi escrito que podem levar a possíveis ocorrências de erros ou defeitos no futuro ou ainda impedir ou dificultar muito a manutenção e evolução do software então como eu falei o software funciona Apesar desses ma cheiros de código pelo menos no início porém e esse tipo de
característica de código ele dá a sugestão de que podem ter havido formas eh pouco elegantes de implementação ou seja o código pode ter sido mal implementado e que isso poderá acarretar problemas no futuro e também que áreas do código precisariam ser melhoradas precisariam ser refatorado bom ah existem basicamente cinco grandes grupos de ma cheiros de código são os blots que representam excesso de código os Object orientation abusers que são eh os abusadores de orientação objetos são tipos de erro que tipos de de de estrutura de código que eh levam a concluir que houve um abuso
da orientação objeto eh existe o grupo dos Change prevent ou impedidores de mudança que dificultam muito a manutenção ou evolução do código tem o dispensa que são basicamente código desnecessário código que pode ser dispensado e tem os couplers que é que são relacionados a código com acoplamento excessivo nós vamos falar um pouco sobre cada um desses grupos mas nessa aula nós vamos nos concentrar nos blotters bom então os blotters em português se traduziria por inchados ou Aren arenques defumados porque é um tipo de peixe que tem um cheiro forte ã então basicamente os blotters eles
eh se caracterizam por [Música] eh possuírem códigos a verem trechos do código ã ou de métodos ou de classes que foram aumentando muito ao longo do tempo e chega um momento que eles estão muito grandes e isso impede ou dificulta muito trabalhar com esse código extenso normalmente esse tipo de mau cheiro ele não ocorre de forma imediata mas vai ah crescendo Vai acumulando ah a medida que o software vai sofrendo manutenções então o código inicia pequeno e razoavelmente elegante mas ao longo do tempo ao longo das manutenções Por uma questão de eh prazos curtos eh
esse código vai aumentando E também porque ninguém tenta refaturar ninguém tenta melhorar esse código então ele vai eh crescendo naturalmente bom então ah os principais eh maus cheiros de código do tipo bloter são métodos longos classes grandes obsessão primitiva métodos com listas de parâmetros com longas listas de parâmetros e aglomerados de dados vamos falar um pouquinho sobre cada um deles bom os métodos longos o nome já diz são métodos que possuem muitas linhas de código eles são métodos extensos Ah isso ocorre muitas vezes quando o método possui mais responsabilidades do que deveria isso torna o
método difícil de entender e de alterar de evoluir de manter Então se sugere quando ocorre esse tipo de situação dividir o método em vários métodos menores e Mais coesos na verdade e eu acho isso talvez um pouco exagerado se afirma que qualquer método que tenha mais do que 10 linhas deve ser suspeito de ser um bloter eu acho isso um pouquinho exagerado mas existe essa afirmação Quais são as razões para o problema dos métodos longos então H ao longo do tempo vai sempre se acrescentando novo código ao método e nunca nada é retirado então os
métodos acabam ficando muito extensos Ah claro que existem eh princípios que declaram que deve se fazer refaturar esse tipo de coisa mas nem sempre H se consegue cumprir esse em princípio às vezes prazos muito curtos ou mesmo programadores preguiçosos terminam deixando se passar bom mas como tratar esse mau cheiro Existem algumas formas primeiro extraia novos métodos ou seja divida o método em Pates menores em métodos menores E H selecione blocos de código que tenham um determinado propósito e coloque esse esse esses blocos em m separados com nomes descritivos intuitivos Ou seja que facilitem a comprensão
da sua função e isso melhora a clareza do código deixa o código menor deixa ele mais fácil de entender e também de reutilizar Ah uma outra forma eh também é substituir comentários por métodos então basicamente se afirma que se é necessário comentar algo dentro de um método Então isto esse código que foi comentado ele precisa ser retirado e colocá-lo e colocá-lo e colocado no novo método certo no caso assim comentado quer dizer não que o código tenha sido comentado mas que tenham sido colocados comentários a respeito do código ah os Defensores dessa prática eles afirmam
que mesmo uma única linha pode ser dividida em um método novo se for necessário explicar essa linha de código e eles também defendem que o um nome descritivo para o novo método ele iria substituir a necessidade de comentários eh extensivos uma outra forma de tratar é introduzir parâmetros de objetos Lembrando que todos esses tratamentos podem ser utilizados em conjunto Ah então numa situação que o método está recebendo muitos parâmetros o que por si só pode caracterizar um outro ma cheiro de código então pode-se por exemplo criar objetos que encapsula esses dados Ah isso irá reduzir
a complexidade do método e melhorar a organização do código como um todo um outro uma outra forma de tratar é procurar e remover código duplicado na verdade esse é um erro grave que deve ser evitado código duplicado é sempre uma péssima característica de um de um código então deve se procurar por código repetido E caso se encontre extrair os tros duplicados e criar métodos que contenham esse esse código que foi retirado e esse método deve ser chamado sempre que for necessário Executar a aquele trecho de código então isso torna o código muito mais elegante muito
menor muito mais fácil de entender muito mais fácil de manter uma vez que se eu tiver código duplicado quando eu tiver que alterar esse código eu tenho que procurar toda vez que ele ocorre então código duplicado é uma péssima prática Ah um outro tipo de tratamento é aplicar padrões de projeto então Eh quando existe muita lógica condicional em o método pode-se pensar em aplicar os padrões de projeto como por exemplo strategy ou Command para procurar modularizar a lógica do código e evitar que hajam blocos muito grandes de código dentro de um mesmo método finalmente se
recomenda então ainda que se melhora a nomenclatura Então deve refaturar o método procurando por nomes de variáveis nomes de métodos nomes de classes e tentar verificar se esses nomes eles são descritivos intuitivos que se ao ler se entende Qual é a sua função nomes claros e significativos eles ajudam a reduzir a necessidade de comentários e torna o código mais alto explicativo Qual é a recompensa para fazer esses tipo de refaturar nós teremos classes com métodos curtos e Por conseguinte métodos curtos costumam ter vida mais longa esses métodos Eles serão mais fáceis de entender e serão
mais fáceis de manter e evoluir Ah há uma questão que às vezes se pergunta se eh Se aumentar muito o número de métodos o desempenho do código irá piorar na verdade segundo já foram feit segundo estudos que já foram feitos comparações que já foram feitas e na maioria das vezes o impacto é muito pequeno então não dá para considerar e na verdade quando se tem um código Claro e compreensível é mais fácil encontrar métodos efetivos para reestruturar o código e assim conseguir ganhos de desempenho reais Se isso for um objetivo agora vamos falar de um
outro ah mau cheiro de código que são as classes grandes também esse esse mau cheiro ele é autoexplicativo basicamente ele ocorre quando existem classes que contém muitos Campos muitos métodos muitas linhas de código ah existe um princípio que é o princípio de responsabilidade única o single responsability principle ou srp que prescreve que cada classe deve ter apenas uma responsabilidade então quando ocorre de existirem classes grandes o recomendável é que ela seja dividida em classes menores Quais são as razões para esse problema as classes em geral elas iniciam pequenas mas ao longo do tempo mais ou
menos a exemplo do macheiro anterior de métodos longos vai se adicionando código vai se adicionando métodos vai se adicionando atributos e etc e a as classes elas vão se tornando mais inchadas ao longo do das manutenções que o software sofre Então os programadores eles em geral acham mais fácil colocar novas características de uma classe que já existe do que criar uma nova classe basicamente isso envolve um pouco de preguiça então não se cria uma nova classe vamos seguir adicionando coisas a uma classe que já existe e isso pode terminar causando problemas o código fica difícil
de manter erros costumam ser se esconder numa classe maior bom como tratar Então existe algumas formas quando uma classe ela possui muitas funções Então ela deve ser dividida na maioria dos casos Então se pode por exemplo extrair classes isso ajuda se o comportamento se parte do comportamento da classe pode ser desmembrado em classes separadas ou então pode subclasses se parte do comportamento da classe pode ser implementado de maneiras diferentes ou ainda pode se extrair interfaces se é necessário ter uma lista das operações e comportamentos que o cliente pode utilizar Ah ainda se uma classe ela
for grande e ela é responsável pela interface gráfica então uma alternativa seria tentar mover alguns dos seus dados e comportamentos Para um objeto de domínio separado bom qual é a recompensa ao refaturar uma classe grande em classes menores ou alguma das outras alternativas que foi explicada ã isso evita a duplicação de código e de funcionalidades irá facilitar a compreensão e manutenção das classes um outro macheiro de código do tipo ploter é a obsessão a obsessão primitiva ou primitive Obsession então esse tipo de ma cheiro ocorre quando há um uso muito grande de tipos de dados
primitivos como por exemplo ent char float Double etc ou mesmo uso excessivo de constantes hã e esses tipos primitivos eles são eh utilizados para representar conceitos mais complexos que poderiam eventualmente ser melhor encapsulados em objetos Quais são as razões para problema então é uma questão também de preguiça um momento de fraqueza muitas vezes criar um campo primitivo é mais fácil do que criar uma nova classe e aí depois que se utilizou essa abordagem vamos dizer assim preguiçosa ã surge imediatamente uma nova situação que outro campo é necessário e ele vai ser adicionado da mesma forma
até que a classe se torne muito grande e pesada difícil de Difícil de Entender Difícil de manter Ah um outro exemplo ã pode ser também a simulação de Campo que ocorre quando uma classe Ela utiliza um vetor e utiliza constantes do tipo string ou inteiros como índices para acessar os elementos do vetor Aqui nós temos um exemplo onde eu tenho um um vetor que foi chamo vetor de string que foi chamado de cliente cliente dados e vocês podem perceber que cada ã entrada desse vetor cada elemento desse vetor recebe um valor ã relacionado a um
cliente então o cliente de dados índice um recebe o valor João o cliente de dados índice um Aliás o cliente de dados índice zero recebe o valor João o cliente dados índice 1 recebe valor ruaa o cliente dados índice 2 recebe valor 1 2 3 4 5 e assim sucessivamente e os dados são São ã recuperados a através de índices então eu tô dizendo aqui por exemplo que a a variável o nome do tipo string recebe o valor do vetor cliente dados índice zero bom isso não é a forma mais inteligente de eh abordar esse
problema uma uma forma mais inteligente mais elegante mais correta seria criar uma classe chamada cliente e colocar H atributos para representar cada um dos Campos do cliente como nome endereço telefônico então Eh criar o método Construtor para instanciar cada um dos clientes que são manipulados pelo software atribuindo ã valores para cada um dos seus atributos específicos bom eh alguns problemas relacionados a a obsessão primitiva primeiro falta de abstração então o uso de tipos primitivos quando são utilizados para representar entidades complexas ele costuma resultar em um código que é difícil de entender e é difícil de
manter porque os detalhes da implementação podem estar espalhados em várias partes do código eh uma outra um outro problema é a falta de encapsulamento Então os dados que poderiam estar encapsulados em uma classe eles vão ser manipulados diretamente o que é perigoso e aumenta a a probabilidade de erros uma outra um outro problema que pode ocorrer é a repetição de lógica Quando se usa tipos primitivos Às vezes a lógica para manipular esses dados ele ela precisa ser ser duplicada em vários lugares e como já foi falado isso é uma péssima prática eh continuando também existe
a questão de dificuldade de manutenção já que já são problemas com simulação de campo então se os índices mudarem todo o código relacionado a eles precisará ser ajustado também isso irá aumentar a complexidade e a a probabilidade que ainda um outro problema é relacionado ao código difícil de entender então Eh ao se utilizar esse tipo de índice o se pede muito do contexto relacionado ao que os dados representam então isso prejudica a legibilidade do código bom Como tratar a obsessão primitiva Então se Existem muitos Campos do tipo primitivo eh uma alternativa seria agrupar logicamente alguns
deles em classes próprias relacionados ao domínio do problema e se possível incluir algum comportamento associado a esses campos ã Qual é a recompensa para isso então o código se torna mais flexível já que estamos utilizando objetos ao inv tipos primitivos há uma melhor compreensibilidade e organização de código e há uma maior facilidade em encontrar código duplicado agora vamos falar sobre métodos com longa listas de parâmetros com longas listas de parâmetros então o nome já diz eles se caracterizam por métodos que possuem mais do que três ou quatro parâmetros as razões para esse problema podem ser
por exemplo que ã ao longo do tempo diversos tipos de algoritmos foram mesclados em um método único isso não é uma alternativa muito inteligente na maioria das vezes porque vai ocorrer em outros ma cheiros de código que já foram falados anteriormente como métodos longos por exemplo então uma lista longa pode ter sido criada para controlar qual algoritmo será executado e como e isso também pode ser subproduto de esforços para tornar as classes mais Independentes então por exemplo o código para criar objetos específicos necessários a um método ele foi movido do método em si para o
código utilizado para chamar o método mas objetos que foram criados eles são passados para o método como parâmetros E assim a classe original ela deixa de ter conhecimento sobre os relacionamentos entre os objetos e a dependência então diminui mas se diversos desses objetos são criados então cada cada um deles irá requerir os seu próprio parâmetro O que significa uma lista de parâmetros maior e isso faz com que seja difícil compreender essas listas essas listas elas podem se tornar contraditórias ã e serem difíceis de usar ao à medida em que elas vão crescendo então ao invés
de uma longa lista de parâmetros o método ele poderia utilizar os dados de seu próprio objeto se o objeto corrente não contém todos os dados necessários outro objeto pode ser passado com o parâmetro de método bom então vamos falar sobre o tratamento deste machir então deve-se verificar quais valores são passados como parâmetros se algum dos argumentos se algum dos parâmetros são o resultado de chamada de métodos de outro objeto então deve-se tentar substituir o valor passado como parâmetro inserido o código que obtém o valor dentro do método então uma outra forma ao invés de passar
um grupo de dados recebidos de outro objeto com parâmetros deve tentar passar o próprio objeto para o método e se existem diversos elementos de dados não relacionados pode-se tentar mesclar esses elementos em um único objeto parâmetro Qual a recompensa para refatorar métodos com longas listas de parâmetros maior legibilidade código mais curto e identificação e eliminação de código duplicado Vamos falar agora sobre o último ma cheiro desta aula que é o o aglomerado de dados ou data clan esse tipo de macheiro ele ocorre quando partes diferentes do código contém grupos idênticos de variáveis então esses aglomerados
de dados obviamente eles deveriam ser movidos para suas próprias classes ou métodos porque esse é um código que vai ã que está se repetindo é código duplicado código duplicado é uma péssima característica de um código ã por exemplo se eu tiver que dar manutenção num código que está duplicado eu tenho que procurar todas as vezes que ele ocorre caso contrário o meu código fica inconsistente então mover esse código que se repete para uma específica e ou um método específico torna o código mais claro e torna a manutenção e a evolução do software mais fácil Quais
são as razões para o problema então esses grupos de dados eles muitas vezes se devem a uma estrutura de programação pobre ou então a cópia de programação cópia de código tratamento como nós tratamos este mau cheiro então ah se os dados repetidos eles compreendem os campos de uma classe Então se cria uma classe supondo que ela ainda não exista e se move os campos para classe já se os mesmos aglomerados de dados eles são passados nos parâmetros de métodos Então se substitui esses aglomerados por um objeto é praticamente a mesma alternativa anterior ainda se algum
dos dados é passado para outros métodos Então deve pensar em passar o objeto inteiro ã deve-se verificar o código que é usado pelos Campos e determinar se vale a pena mover este código para uma classe Qual a recompensa a refatoração dos aglomerados de dados melhora a compreensibilidade e organização de código ah operações sobre dados particulares são colocadas em um único lugar e ao invés de estarem espalhadas ao longo do código então isso eh corrige o problema de duplicação eh e também reduz o tamanho do código e nós terminamos a nossa primeira aula sobre ma cheiros
de código eu espero que essa aula tenha sido considerada razoável Ah então se vocês gostaram desse vídeo eu peço que vocês curtam esse vídeo se vocês ainda não estão inscritos eu peço que vocês se inscrevam e se vocês conhecerem interessado nesse tipo de conteúdo compartilhem esse conteúdo com essas pessoas obrigado pela atenção nós nos vemos na próxima aula
